Open Makhaira opened 3 years ago
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. If you can reproduce the crash, tell me how.
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, notifications@github.com 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 https://github.com/supermerill/SuperSlicer/issues/854#issuecomment-757485399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOKLI6UTGECUEP2KS6VD6PLSZG2TDANCNFSM4VWCKXKQ .
No crash log. If you can reproduce the crash, tell me how.
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.
is it possible to somehow enable crashlog or crashdump?
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.
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: https://github.com/supermerill/SuperSlicer/blob/b8ac45e03188ef5d733e730ab053103c3688998d/src/slic3r/GUI/GLTexture.cpp#L267
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 auto_toolbar_size
, which seems to be set to -20 somewhere, though I haven't yet investigated further, to find where that value comes from (in my config it's set to 100).
This value gets factored into the icon scale at: https://github.com/supermerill/SuperSlicer/blob/b8ac45e03188ef5d733e730ab053103c3688998d/src/slic3r/GUI/GUI_App.cpp#L1191
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 ENABLE_RETINA_GL
define. This is set both for apple and for GTK3 (note the comment): https://github.com/supermerill/SuperSlicer/blob/b8ac45e03188ef5d733e730ab053103c3688998d/src/slic3r/GUI/GLCanvas3D.hpp#L33-L35
https://github.com/supermerill/SuperSlicer/blob/b8ac45e03188ef5d733e730ab053103c3688998d/src/slic3r/GUI/GLCanvas3D.cpp#L5383-L5392
Meanwhile, in several places where retina related values are calculated, the __APPLE__
define is used instead. For instance in the function that calculates the scaling: https://github.com/supermerill/SuperSlicer/blob/b8ac45e03188ef5d733e730ab053103c3688998d/src/slic3r/GUI/GUI_App.cpp#L1181-L1187
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 auto_toolbar_size
). However, I just thought I'd mention, as I suspect there might be some other bugs hiding in the HiDPI implementation. In any case, this is probably not even SuperSlicer-specific, as this code seems to come from upstream.
Thank you very much for your debugging investigation.
For the fix, I propose to change for (adding the last if)
const std::string& use_val = app_config->get("use_custom_toolbar_size");
const std::string& val = app_config->get("custom_toolbar_size");
const std::string& auto_val = app_config->get("auto_toolbar_size");
if (val.empty() || auto_val.empty() || use_val.empty())
return icon_sc;
int int_val = use_val == "0" ? 100 : atoi(val.c_str());
// correct value in respect to auto_toolbar_size
int_val = std::min(atoi(auto_val.c_str()), int_val);
if (is_limited && int_val < 50)
int_val = 50;
else if (int_val < 1) {
int_val = std::max(1, std::min(100, int_val)); //buggy code? issue supermerill/superslicer#854
assert(false);
}
auto_toolbar_size
doesn't seem to be set by anything and isn't used anywhere else... Maybe prusa needs it for something (it was added in may 2020) but forgot about it?
For the ENABLE_RETINA_GL
vs __APPLE__
These kinds of GUI things are extremely time-consuming. I let prusa investigate & fix them. If you can test gtk3 with & without and find the diff, you may be able to fix it for them.
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. Let's be real, I can't replicate the issue., and I won't spend days hunting it. So until someone (or prusa) comes with a better solution... it's better than nothing. Does it work on your computer if you compile with the fix?
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.
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?