Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slic3r hangs with Strawberry Perl 5.24.0.1 / 64bit #3561

Closed
bubnikv opened this issue Nov 6, 2016 · 5 comments
Closed

Slic3r hangs with Strawberry Perl 5.24.0.1 / 64bit #3561

bubnikv opened this issue Nov 6, 2016 · 5 comments
Labels
OS: Windows Upstream issue Root cause of issue is not in Slic3r codebase

Comments

@bubnikv
Copy link
Contributor

bubnikv commented Nov 6, 2016

Slic3r hangs when a C++ exception is thrown / catched and a subsequent perl croak() function is executed. This makes a 64bit build on Windows / Strawberry Perl hang every time a c++ exception is used to relay a return value. For example, Slic3r hangs if objects do not fit the print bed.

The problem is caused by the Strawberry Perl. I don't see a simple cure. In the Prusa3D fork I re-wrote the most critical C++ code (automatic component placement on the bed, print validation) to not throw exceptions, but my gut feeling is this is not enough. Considering to prepare a "Vojtech's own Perl" distribution for Windows 64bit and Visual Studio 2013, containing all the libraries precompiled.

@bubnikv
Copy link
Contributor Author

bubnikv commented Nov 6, 2016

Tested with Strawberry 5.18.4.1, 5.20.0.1, 5.20.2.1, 5.24.0.1.
Strawberry 32bit builds work all right, but the last Strawberry 64bit build working correctly is 5.18.4.1. Starting with 5.20.0.1, the C++ exceptions together with a croak() lead to a hangup. Very possibly one gets the same hangup when running one of the test cases of Perl Wx module.

I created a test case to test for the broken C++ exceptions:
prusa3d/PrusaSlicer@aac9681

@bubnikv
Copy link
Contributor Author

bubnikv commented Nov 6, 2016

Very possibly one gets the same hangup when running one of the test cases of Perl Wx module.

Indeed, I have not had the usual hangup of a test case of the Wx package with Strawberry Perl 5.18.4.1 64bit.

@alranel
Copy link
Member

alranel commented Mar 13, 2017

@bubnikv
Copy link
Contributor Author

bubnikv commented Mar 13, 2017

A possible solution is to use the Visual Studio perl builds.

https://bintray.com/bubnikv/wxPerl-for-Slic3r-with-VisualStudio/wperl

@lordofhyphens
Copy link
Member

It's not specifically Perl, it's GCC and the exception model used with MinGW-GCC (SJLJ). Specifically, GCC > 4.8 with sjlj has this bug (and it affects more than Slic3r). Newer Mingw-GCC versions (>5.4.0) have SEH exceptions enabled and those should be used instead of SJLJ.

I've modified Perl-Dist-Strawberry to use Mingw64 6.3.0 with SEH exceptions and stripped out most of the unused modules (that aren't in CORE anyway). There were some other "interesting" things I had to deal with (at least on my system).

https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r-perl-5.24.1.4-64bit-portable.zip
https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r-perl-5.24.1.4-64bit.msi
https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r-perl-5.24.1.4-64bit.zip

We can stop using our version after an upstream version of Strawberry Perl uses one of the SEH builds or we shed the need for perl.
See #3815

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS: Windows Upstream issue Root cause of issue is not in Slic3r codebase
Projects
None yet
Development

No branches or pull requests

3 participants