Skip Menu |

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics
Id: 118635
Status: open
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: Nobody in particular
Requestors: bubnikv [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: XS modules hang on croak() called from an exception handler
Date: Sat, 5 Nov 2016 17:47:33 +0100
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: "bubnikv ." <bubnikv [...] gmail.com>
Dear Strawberry Perl maintainers. Some Strawberry builds have a fatal issue with handling croaks from a catch block of an exception handler in an XS module. A simple C++ construct like this leads to a perl interpreter hangup. try { ... } catch (excepton &e) { croak("%s\n", e.what()); } I am certainly not the first to find out: https://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225230.html The problem makes some features of the Slic3r application unusable. Namely, if the "croak" is used to relay a return value of some validation, the application hangs without a warning. https://github.com/alexrj/Slic3r https://github.com/prusa3d/Slic3r strawberry-perl 5.24.0.1 64bit is broken, strawberry-perl 5.22.1.3 both 32 and 64bit are ok. Right now I will downgrade the Strawberry perl on our build system and I will inform our Slic3r users, but it would be great, if it could be fixed, and maybe a test added to an automatic test suite of the Strawberry Perl builds. Thanks for looking into this issue, Vojtech
Subject: Re: [rt.cpan.org #118635] XS modules hang on croak() called from an exception handler
Date: Thu, 1 Dec 2016 20:08:10 +0100
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
As you probably know it is more a perl core issue than strawberry perl issue, so p5p mailing list is for sure a better place for discussing the fix. I do not think we can anything about this in strawberry perl 5.24.x series. However in 5.26.x (May 2017) we will definitely switch to newer gcc compiler and we can consider also switching from SJLJ to SEH. Anyway, as SEH is AFAIK available only got 64bit gcc target I am afraid that there will be no way how to fix it for 32bit. -- kmx