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

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

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

Comments

Projects
None yet
7 participants
@justmyopinion

justmyopinion commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 9, 2015

Member

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

Member

alexrj commented Jan 9, 2015

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

@justmyopinion

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 9, 2015

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

justmyopinion commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 9, 2015

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

justmyopinion commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 9, 2015

Member

Works fine on OS X. Will try on Windows.

Member

alexrj commented Jan 9, 2015

Works fine on OS X. Will try on Windows.

@justmyopinion

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 9, 2015

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

justmyopinion commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 9, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 9, 2015

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 commented Jan 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 9, 2015

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

justmyopinion commented Jan 9, 2015

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

@braddo99

This comment has been minimized.

Show comment
Hide comment
@braddo99

braddo99 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?)

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

This comment has been minimized.

Show comment
Hide comment
@natevw

natevw 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 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

This comment has been minimized.

Show comment
Hide comment
@natevw

natevw 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.

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

This comment has been minimized.

Show comment
Hide comment
@awdemuth

awdemuth Jan 16, 2015

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

awdemuth commented Jan 16, 2015

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

@zsolta

This comment has been minimized.

Show comment
Hide comment
@zsolta

zsolta 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

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 18, 2015

Member

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.

Member

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.

@alexrj alexrj removed the Needs 3D Model label Jan 18, 2015

@justmyopinion

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 18, 2015

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.

justmyopinion commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 18, 2015

Member

Ouch...

Member

alexrj commented Jan 18, 2015

Ouch...

@awdemuth

This comment has been minimized.

Show comment
Hide comment
@awdemuth

awdemuth Jan 18, 2015

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).

awdemuth commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 18, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 18, 2015

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

justmyopinion commented Jan 18, 2015

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

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 18, 2015

Member

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

Member

alexrj commented Jan 18, 2015

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

alexrj added a commit that referenced this issue Jan 18, 2015

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 18, 2015

Member

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.

Member

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.

@justmyopinion

This comment has been minimized.

Show comment
Hide comment
@justmyopinion

justmyopinion Jan 18, 2015

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.

justmyopinion commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@braddo99

braddo99 Jan 21, 2015

Fantastic!

braddo99 commented Jan 21, 2015

Fantastic!

@gege2b

This comment has been minimized.

Show comment
Hide comment
@gege2b

gege2b Jan 22, 2015

Contributor

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

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