V1.2.5 W7/64 crash at random when exporting gcode #2517

Closed
justmyopinion opened this Issue Jan 9, 2015 · 24 comments

Projects

None yet

7 participants

@justmyopinion

Tested numerous STL files and quite a lot made Slic3R crash with no error showing but win message
"Slic3r.exe stopped working" with a some debug info available.
Crash is random which means that it does not crash at every try, but always when export button pressed but before save is executed.
Default settings used with Win7/64

But otherwise Slic3r looks marvelous at the moment, with exciting features :-)

Win Errormsg:

errormsg

@alexrj
Owner
alexrj commented Jan 9, 2015

Okay, thanks, but without reproducible test cases (STL files and config) I can do nothing...

@justmyopinion

Config is default, and STL files many, see if I can load one here.

@alexrj alexrj added this to the 1.2.6 milestone Jan 9, 2015
@justmyopinion

You may try this one with default settings:
https://www.dropbox.com/s/9l4ngqdh9pfm3bx/Ball_in_a_box.stl?dl=0

Drag and drop file and press export and before this happens Slic3r leave windows with error

@alexrj
Owner
alexrj commented Jan 9, 2015

Works fine on OS X. Will try on Windows.

@justmyopinion

Unfortunately case is random and i have to delete all from plater and load again to make it happen.
Pressing export several times does not trigger or al least I have not seen this.

Win Exception code is: c0000005

@alexrj
Owner
alexrj commented Jan 9, 2015

Hmm, it looks like this is model-independent and is actually related to TCP/IP networking. Slic3r does networking only for version checking and for OctoPrint upload.

@justmyopinion

Yet it never happens during load or background processing.
Some timing may be involved for pressing export during initial background processing?

I have also seen it happen with export STL!

Do I have a local win problem?

@justmyopinion

Tried to provoke v1.2.4 with same files and default and I can actually do the same but not so frequently

@braddo99
braddo99 commented Jan 9, 2015

I have this problem with 1.2.5 and also had it with 1.2.4 Running windows7 64bit on two different machines. One perhaps unusual aspect of my install is I'm running with slic3r in a dropbox folder. I have an object which crashes consistently for me. I noticed a few things. I can successfully export to OP even though test OP connection doesn't work (maybe because no bonjour installed?) Crash only some time after Export Gcode, not immediately. After Export Gcode, the Export STL button flashes (why?)

@natevw
natevw commented Jan 13, 2015

This crash happens pretty reliably for me in 1.2.5 under same W7/64 setup:

  1. Plate up model, do whatever config, etc. — program is fine
  2. Click "Export G-Code"
  3. Slic3r always crashes (same BEX64 IPHLPAPI.DLL_unloaded stuff as above) while the Save dialog is up!

I do not have any OctoPrint set up, just copied a config.ini from stable version into 1.2.5 download.

@natevw
natevw commented Jan 13, 2015

It seems to have something to do with the background rendering, if I get through "Export G-code…" save dialog while it is still e.g. "Generating perimeters" it worked fine but the first two times when it crashed, it was all done with that background work before I tried to export.

@awdemuth

Just chiming in to confirm I'm experiencing the same issue, version 1.2.5 64 bit, under Windows 8.

@zsolta
zsolta commented Jan 17, 2015

Similar happened to me. Slic3r 1.2.5 crashes randomly after a few G-Code exports. Sometimes crashes during the first export, sometimes I manage doing a few of them, but it also crashed when I selected stl files to add them to the plate. Tested with various stl files. The error log looks like:

capture

Win7/64 platform, Slic3r 1.2.5

@alexrj
Owner
alexrj commented Jan 18, 2015

Can you try disabling the automatic version check? It's located in Preferences. I think that might be the culprit because of some issue with calling IPHLPAPI.DLL in a background thread. Let me know.

@justmyopinion

It was never checked during my testing:
update

Chrashing frequency is raised massive if you change any parameter before exporting.
At the moment this release is close to useless because of this.

@alexrj
Owner
alexrj commented Jan 18, 2015

Ouch...

@awdemuth

I've tried that already, along with disabling Octoprint, trying another
wireless AP, going hardwired, and disconnecting from the network completely
(somebody said it could be a network issue, so I tried everything I could
do regarding the network).

On Sun, Jan 18, 2015 at 6:15 AM, Alessandro Ranellucci <
notifications@github.com> wrote:

Can you try disabling the automatic version check? It's located in
Preferences. I think that might be the culprit because of some issue with
calling IPHLPAPI.DLL in a background thread. Let me know.


Reply to this email directly or view it on GitHub
#2517 (comment).

@alexrj
Owner
alexrj commented Jan 18, 2015

I'm puzzled. IPHLPAPI.DLL is a Windows-specific library that deals with networking. The only way I can reproduce the issue is to load a file into the plater and select "Check for Updates..." in the Help menu. Slic3r fails during the HTTP call. I can't reproduce it when using the Test button for OctoPrint, although the two things do exactly the same operations. I'm trying to investigate deeper. It looks like the crash is triggered by the inet_aton() call in IO::Socket::INET.

@justmyopinion

can it be for sure that "check for updates " is activated somehow even if unchecked in preferences

@alexrj
Owner
alexrj commented Jan 18, 2015

Note to self, this might be relevant: https://rt.perl.org/Public/Bug/Display.html?id=97860

@alexrj alexrj added a commit that referenced this issue Jan 18, 2015
@alexrj Require an up-to-date Win32::API version because older ones are not t…
…hread-safe and cause random segfaults. #2517
3648bbd
@alexrj
Owner
alexrj commented Jan 18, 2015

Good news. After a long debugging session I found that the problem was the Win32::API module whose older versions were not thread-safe. When a background thread finished its work, said module would unload all the DLLs, causing bad memory access when gethostbyname() was called (note to self: Socket::inet_aton() calls gethostbyname() internally).
After upgrading Win32::API to the newest version (0.79) I could not reproduce the issue in any way.

I also found that a third thing in Slic3r was using the TCP/IP stack: Growl::GNTP notifications. So that's why @justmyopinion was getting the segfault even when not using the version check or the Octoprint features.

As always, feel free to raise this again should the issue arise in 1.2.6. I'm going to release it soon.

@alexrj alexrj closed this Jan 18, 2015
@alexrj alexrj added Fixed Win7 labels Jan 18, 2015
@justmyopinion

Thankyou Alex
Looking forward to give this a real life test with new version available.
Appreciate your hard work and curious to see new functionality and performance coming ahead.

@braddo99

Fantastic!

@gege2b
Contributor
gege2b commented Jan 22, 2015

Oh great news ! can't wait to test the 1.2.6 on my Win7 PCs
1.2.5 is simply unusable for me
I'll switch back to 1.2.4b until the new exp is released

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment