Crashes to desktop (no errors) #854
Comments
|
I can confirm, past few weeks I also get random crashes, usually once a day, nothing serious if you use ctrl+s a lot, but still. No error, just straight quit. |
|
No crash log. |
|
Seems to be having a picture assigned to the bed from what I can deduce so
far
…On Sun, 10 Jan 2021, 14:29 Merill, ***@***.***> wrote:
No crash log i known.
If you can reproduce the crash, tell me how.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#854 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOKLI6UTGECUEP2KS6VD6PLSZG2TDANCNFSM4VWCKXKQ>
.
|
is it possible to somehow enable crashlog or crashdump? I get totally random crashes but only once every two days. I didn't spot any correlation to what I do, which STLs I use, etc. |
|
I fixed many bugs that can crash the slicer, so hopefully the current stable shoudln't crash anymore.
only if built with debug flags. I can give you one. |
|
I'm having the same issue (or at least the same symptom), on Linux. The latest official release build crashes immediately upon launch, but not consistently (perhaps about 50% of the time, or a bit more). I'm not sure if it's the same issue and/or if it's platform specific, but since it's the same symptom, I figured it'd make sense to reply here. Since the official build seems to conveniently include debug symbols, I was able to generate the backtrace below. I haven't had time to get the master branch building to look into it myself, but I hope this helps with finding the issue. Backtrace |
|
Had some time to make a build and look a bit further into the issue, so I have a bit of additional info. My crash is ultimately an out of bounds access at: SuperSlicer/src/slic3r/GUI/GLTexture.cpp Line 267 in b8ac45e However, the actual cause happens much earlier. The issue is that the icon scale is set to a negative value, which ends up causing an underflow (and later a subsequent overflow) of the unsigned sprite size (in the function referenced above). I've traced the negative value back to This value gets factored into the icon scale at: SuperSlicer/src/slic3r/GUI/GUI_App.cpp Line 1191 in b8ac45e As a side note, from my investigation, I'm a bit suspicious of the retina display handling. The code decides whether to set the icon scale (to a value other than the default of 1.0), based on the SuperSlicer/src/slic3r/GUI/GLCanvas3D.hpp Lines 33 to 35 in b8ac45e SuperSlicer/src/slic3r/GUI/GLCanvas3D.cpp Lines 5383 to 5392 in b8ac45e Meanwhile, in several places where retina related values are calculated, the SuperSlicer/src/slic3r/GUI/GUI_App.cpp Lines 1181 to 1187 in b8ac45e This might be intentional, if it's dealing with some discrepancies between OSX and wxGTK, but it might also be a mistake in that part of the code, assuming that only Apple has HiDPI. I was suspicious of this, particularly because of the comment claiming that wxGTK3 simulates OSX HiDPI handling. In any case, whether or not my suspicions turn out to be warranted, this is not the cause of the crash (that'd be the negative |
|
Thank you very much for your debugging investigation. For the fix, I propose to change for (adding the last if)
For the |
|
While I agree that your proposed code mitigates the issue, I wonder if this is a wise decision, as it just hides the actual issue that is further up. I feel like other unexpected issues could easily crop up from this. For instance, if this setting happens to be used anywhere else, the values won't match. And besides, if this setting is somehow being changed somewhere, it is also plausible to imagine that the bug might affect other settings as well. Of course, it's not up to me, and I'm very new to this codebase, but I'd advise against this sort of band-aid. Though I do admit that it's good to have a safeguard (such as what you wrote), in case users set the setting itself to an implausible value. But in this case, it'd be good to also find where the actual issue is coming from. As for the retina handling, yeah, I figured it's mostly a job for upstream, as it is indeed a lot of very dense code, but I figured I'd bring it up just in case. But it's not really important. |
|
That's why I added the assert, so it can trigger if it's on debug mode. |
Icons can get scaled even if the window is not yet fully initialised, in which case they ended up with a negative scale. Potentially related to supermerill#854
|
Had some time to debug further, and come up with a proper fix (though, to answer your question, yes, your change did stop the crash from happening). I've submitted the fix at #2368, which addresses the source of the negative value. This problem seems to be caused by the canvas not being fully initialised when icon scaling starts being applied. Though I tested on another system and didn't hit the crash, so it seems to be dependent on which WM is used. With any luck this is the same crash as in the original report, though at this point it's looking unlikely. If this crash affected Windows, I'd expect it to crash for everyone on Windows (as it's actually config independent), and since that's not the case, it's probably another issue. |
Icons can get scaled even if the window is not yet fully initialised, in which case they ended up with a negative scale. Potentially related to supermerill#854 Revert "Add a linux startup crash fix." This reverts commit 34ff5c0.
Version
2.2.54
Operating system type + version
Win10
Behavior
SS will frequently crash immediately on launch - the program appears, freezes for a few seconds, and then exists to desktop with no message.
I am also getting some crashes when switching between printer profiles. This is regardless of whether STLs are already loaded or not.
Is there some sort of crash log I could post to help?
The text was updated successfully, but these errors were encountered: