Segfault on arch linux #8299
Comments
|
Thanks, but we are not able to reproduce the problem. If it happens with every version on startup, it is likely to be caused either by a corrupted configuration folder or by some OpenGL issue. You can visit #7274 (comment) and try the three builds that are linked there. If one of them works (or the former two, ideally), it is an OpenGL issue. If that does not help, you can go to |
|
Whoops, wrong button Thanks for the reply, but none of the things you suggested worked for me, still got the same error regardless of what I did. |
|
@maxhambraeus Are you able to provide a backtrace? See #8168 (comment) for instructions if you don't know how to do it. Thanks. |
|
|
Thanks. It seems that wxWidgets did not manage to get your system language. Could you please run prusa-slicer from the command line with an additional |
|
output of
|
|
I had the same problem and solved it by adding the en_GB local. |
|
@maxhambraeus Before you try the advice from @sbraitbart , could you please try the following build: PrusaSlicer-2.4.2+1-lm-languages-crash-linux-x64-GTK3-gec6192a ? I hope it will no longer crash, although I am not sure why wxWidgets fail in providing a system language in the first place. You might need to enter these credentials to download the build: Thanks. |
|
@maxhambraeus If you are still able to reproduce the issue, would you please mind testing the build I provided in my previous post? Thanks. |
|
I reproduced the issue by removing the GB from locals. |
|
Thanks for the testing. The fix will be included in 2.6 release. |
|
Sorry for the delayed reply. |
|
I'm having the same issue. Added en_GB to locale and run locale-gen... Still crashing - The appimage is working fine ! |
|
@feiticeir0 Thanks. Can you be more specific? Which version does not work and what appimage is working fine? |
|
I can confirm. Got a |
|
I can confirm to. |
Hi @maggick ! The version that gives a segmentation fault is The appimage that works fine is Thank you ! |
|
Same problem, gdb with debuginfod enabled: |
|
Two issues are being mixed here. The original issue by @maxhambraeus was a probable nullptr dereference, which I attempted to fix and compiled in a separate branch and provided a build to test, because I was unsure if it really was the issue and I was unable to reproduce it. I am still not sure about it, given the statement that it "did not initially work", we will see. The "issues" reported by @feiticeir0, @maggick , @niklasarnitz and @lodriguez all only appear in Arch package (I assume), although it is not mentioned explicitly in most of the posts. The thing here is, that wxWidgets 3.2 were released, and the package maintainers eagerly switched to it and then rebuilt our beloved PrusaSlicer 2.4 against it, although that wxWidgets version did not even exist at the time of its production and it is not compatible with it. That's why you are getting the crash. And my build works not because of the fix in it, but because it is compiled against wx3.1.4. I assume that if you downloaded a build from our Releases page, it will run fine, regardless of whether it is 2.4.2 or the 2.5.0 alphas. We have an internal build against wx3.1.6 and as far as I remember, we faced a problem with the |
|
@lukasmatena 3.1.x never were stable versions. They broke a lot of other software, so we had to stay on 3.0.x. Once 3.2.0 has been available, we switched to it. Apparently they hasn’t been testing of prusa-slicer after it was rebuilt and before it landed in the repository. I’m not sure though of the path toward fixing this. I guess I should switch prusa-slicer to vendored wxgtk for the time being? |
|
@ArchangeGabriel We solved the never-ending dependency hell on Linux by providing static builds, but that is probably against the packaging philosophy. What I can say as a developer is that upgrading a library is always dangerous and I am not surprised that there are issues. Especially with a major update of a major library such as wxWidgets, it is quite expected. To support that claim, wxWidgets 3.2 change log lists many behavior changes and does not promise the transition to be seamless. And it is not just that. wxWidgets releases take long and we have worked around many bugs - if they fixed them now, the workarounds may start breaking the application. In addition, we have our own fork of wxWidgets with several alterations and link to that. So even the build linked against stock 3.1.4 is different from what we tested and what people download from our Releases page. It would surely be cleaner to have the bugs fixed upstream, wait for a stable version and just use vanilla wxWidgets all the time, but that would mean our users would wait for a long time. So it is what it is. By the way, the fact that 3.1.x were never stable is a result of wxWidgets development scheme (described here). They use the odd-minor versions as "development" and do not maintain API/ABI stability in them. Even-minor releases should keep ABI stability. I am unable to say what solution is possible for you, I do not know what constraints are there nor what "vendored wxgtk" is. From my point of view, these are several scenarios regarding PrusaSlicer 2.4.2 (and upcoming 2.5.x):
The last option means you will develop a different software from ours, even if it starts, things may break. We do not plan to disrupt our own work on PrusaSlicer 2.6.x by backporting the bugfixes into some 2.4.3 release or whatever. There is a branch If my good habits allowed me to say it (which they don't), I would have said that you are doing this to yourself. |
|
So we agree the main issue is wxwidgets dev cycle (spending years in a dev branch before doing an actual release). 3.0.x is not available anymore, the last option is not a good idea either, but “vendored” means the version included in prusa-slicer sources ( |
|
@ArchangeGabriel the cleanest solution I see is writing a wxwidgets-gtk3-31 package (in the AUR) to build prusa-slicer against. |
|
Building against an AUR package is not possible for repo ones. But anyway, prusa-slicer 2.4.2-7 is linking statically the custom wxwidgets version maintained by Prusa. ;) |
|
@ArchangeGabriel I was mostly thinking about the AUR package. |
|
Dear Lukáš, could you point me to the commit, that you applied to the AppImage build: https://prusaslicer:slicer@slicerbuilds.prusa3d.com/files/lm/PrusaSlicer-2.4.2+1-lm-languages-crash-linux-x64-GTK3-gec6192a-202205260856.AppImage, please? On openSUSE Tumbleweed, we use a sane wx version (3.0.5), but also suffer from this segfault! As such, for 2.4.2, as well as master as of 20220825: c3bdf2f, while the AppImage works well. Here the git master traceback: Our other libraries/compilers are quite current. My git build is available here: https://build.opensuse.org/package/live_build_log/home:frispete:3dprinting/PrusaSlicer-git/openSUSE_Tumbleweed/x86_64. Here the backtrace of our released PrusaSlicer package (not the one from my repo): Let me know, if I can provide any additional information! |
|
@frispete There are two issues mixed in this thread:
which I attempted to fix with commit ec6192a .
This one was IMHO caused by the Arch packagers who upgraded wxWidgets to 3.2 (naively thinking that it will work) and then released the binary without trying to run it. This was fixed by using "vendored" wxWidgets when building the package, as described in #8299 (comment). Upgrading the code for wxWidgets 3.2 (for PrusaSlicer 2.6 release) was done by @YuSanka in a private branch and I think it was not a one-liner (but I don't know which of the many changes needed for 3.2 were related to this one). Now, your issue seems to have a similar backtrace to the second one, which I thought would not occur with 3.0.5. If it does, I clearly don't see the whole picture and therefore can hardly help. You can try to apply the patch from (1) to see if it changes anything. I personally doubt it, but it is the only thing I can recommend to try. |
|
Hi Lukáš,
[...]
Yes, you're right, and I need to correct myself here: my claim, we're using wx 3.0.5 was wrong! We provide both builds in openSUSE Tumbleweed, but the packager must enforce the correct selection... Our default version is 3.2.0 now. After forcing the build to really use the 3.0.5 version, PrusaSlicer doesn't crash any more! Unfortunately, this version is also GTK2 based, hence I looked a bit deeper in into the second crash. I believe, this is the result of wxTranslations::Get() returning NULL for some reason. See also here and specifically the note for Applying this patch fixed it for me: Will create a PR, if you like this approach and incline to apply it. I'm going to submit this fix to openSUSE Factory (which gets released as Tumbleweed after acceptance) to get some testing coverage on this approach, but our user base of PrusaSlicer isn't that big, unfortunately. But any result is better than a segfault on startup, isn't it? |
|
@frispete The fix for the The problem is not the missing check for the nullptr, but the fact that the nullptr is there in the first place because of a missing That being said, linking PrusaSlicer 2.5.x and earlier against wxWidgets 3.2 will create other issues. We guess for example that the bitmaps in the application will not scale correctly when system scaling factor differs from 100 %. There may be other problems and the fact that the application starts up really does not guarantee much. The attitude that "any result is better than a segfault on startup" (your words) are apparently acceptable from package-maintainer's point of view, but our goals are a bit higher. I personally don't understand the Linux packaging philosophy and the need for linking everything to anything that is currently considered "default" by someone. It leads to broken applications and customers angry at their authors, who have not caused it. But that is quite off-topic. Short version: if you link PrusaSlicer 2.5.x with wxWidgets 3.2, you will most likely break it. |
|
Okay, understood. Thanks for the open words. I will make sure, that our builds are linked with wx 3.0.5 and leave a note to warn other maintainers to attempt differently! |
|
In return, I used your blunt words to warn anybody touching our builds accordingly. This version went to Factory yesterday evening and was accepted half an hour ago 😉 I do mention this in order to show you, that we take such warnings seriously! |
|
@frispete Thanks. I used to work at SuSE as a package maintainer during my studies in 1999-2000, thus I understand the package manager attitude. Please understand our frustration though, the day has 24 hours, we are pressed to compete with companies that do not spend their effort on Linux fragmentation to make majority of their customers happy. We need to innovate and supporting the Linux fragmentation / legacy systems and libraries is extremely time consuming and frustrating, demanding a lot of energy from us that we would rather invest into innovation. |
|
@bubnikv Please don't get me wrong. I do understand this situation very well, in general and specifically Lukáš's. If I sounded offending, I'm sorry. Back in the beginning of this century, I developed a couple of cross-platform database UIs with Python for different business purposes. Starting with tkinter, I tackled wxPython before ending up with PythonQt. The cross-platform issues with wx were the main reason to move away from it, because having to handle different behaviour on top of a cross-platform toolkit makes it even harder to deal with such differences. Obviously, things didn't change that much since then. I will try my best to protect you from similar requests (to change the wx version) out of the openSUSE software ecosystem. PrusaSlicer is great, btw! Unlike audacity, we never noticed any UX related deficits, hence you must be doing a great job here! |
It is a philosophy currently returning to large parts of the software industry. As companies start to bundle more and more open source libraries in their proprietary application, suddenly significant parts of the whole software landscape are vulnerable to widespread exploits. As the use of these components is often unknown, and the components are frozen at some arbitrary point in time and rarely updated, the impact is huge. Dealing with this problems requires tracking of these components, and updating them in a timely fashion. Both aspects are handled by Linux distributions since ages. By using a single version of wxWidgets (or any other library) for all applications in a distribution reduces the complexity significantly - while libraries on one side interface with applications, on the other side they also interface with the rest of the system: other libraries, kernel, graphics drivers etc. While it may be easier for application developers to target only one specific version of a library the other aspects are no longer covered. How many combinations of hardware, operating systems, drivers etc. do you actually test? |
|
@StefanBruens I missed your post, hence the late reply. Sorry for that. I had written a longer reply, but I ended up auto-censoring most of it. I will only reply to your last question and leave the rest as implied.
We of course only test a limited number of such combinations. However, given the situation described in this thread, where the "official" package did not even start, and now a similar one in #9128, where the "official" package was unable to slice a single file (after turning off tests which detected the problem), I would say that our testing routine could be much worse. |
This fixes a crash similar to <prusa3d/PrusaSlicer#8299>.
This fixes a crash similar to <prusa3d/PrusaSlicer#8299>.
This fixes a crash similar to <prusa3d/PrusaSlicer#8299>.
Description of the bug
When trying to launch prusa-slicer I get the following error:
[1] 101694 segmentation fault (core dumped) prusa-slicerThis happened on every version I tried
Project file & How to reproduce
Install prusa slicer from official repos and launch it.
Alternatively download appimage from releases tab on github and run it.
Checklist of files included above
Version of PrusaSlicer
2.4.2-1 from arch repo, PrusaSlicer-2.4.2+linux-x64-GTK2-202204251127, PrusaSlicer-2.4.0+linux-x64-202112211614 (all of these gave the same error)
Operating system
Arch linux with default kernel 5.17.5-arch1-1
Printer model
ender 3 pro, though very irrelevant
The text was updated successfully, but these errors were encountered: