Closed maxhambraeus closed 2 years ago
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 https://github.com/prusa3d/PrusaSlicer/issues/7274#issuecomment-1098755054 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 ~/.config
, backup the configuration folder PrusaSlicer
by renaming it to e.g. PrusaSlicer-backup` and try again. If it starts, there is something wrong with that configuration and I would be glad if you could zip it and send here (if it contains no sensitive data).
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 https://github.com/prusa3d/PrusaSlicer/issues/8168#issuecomment-1092799924 for instructions if you don't know how to do it. Thanks.
Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find (this=0x8, __c=95 L'_', __pos=0) at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:1247
1247 /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc: No such file or directory.
(gdb) bt
#0 std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find(wchar_t, unsigned long) const (this=0x8, __c=95 L'_', __pos=0)
at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:1247
#1 0x0000000001c574ef in wxString::Find(wxUniChar, bool) const ()
#2 0x0000000001c576f4 in wxString::AfterFirst(wxUniChar) const ()
#3 0x0000000000b7e6b6 in Slic3r::GUI::GUI_App::load_language(wxString, bool) ()
#4 0x0000000000b80860 in Slic3r::GUI::GUI_App::on_init_inner() ()
#5 0x0000000000b83076 in Slic3r::GUI::GUI_App::OnInit() ()
#6 0x0000000001c26023 in wxEntry(int&, wchar_t**) ()
#7 0x0000000000b6a1ba in Slic3r::GUI::GUI_Run(Slic3r::GUI::GUI_InitParams&) ()
#8 0x00000000005b7243 in Slic3r::CLI::run(int, char**) ()
#9 0x000000000057b3e4 in main ()
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 loglevel=5
argument to get some logging? What language do you use in your system?
output of locale
, if that's what you meant by language
LANG=en_SE.UTF-8
LC_CTYPE="en_SE.UTF-8"
LC_NUMERIC="en_SE.UTF-8"
LC_TIME="en_SE.UTF-8"
LC_COLLATE="en_SE.UTF-8"
LC_MONETARY="en_SE.UTF-8"
LC_MESSAGES="en_SE.UTF-8"
LC_PAPER="en_SE.UTF-8"
LC_NAME="en_SE.UTF-8"
LC_ADDRESS="en_SE.UTF-8"
LC_TELEPHONE="en_SE.UTF-8"
LC_MEASUREMENT="en_SE.UTF-8"
LC_IDENTIFICATION="en_SE.UTF-8"
LC_ALL=
prusa-slicer --loglevel=5
[2022-05-10 10:06:36.540207] [0x00007f03d99ae780] [debug] full path: 12755476446117811484
[2022-05-10 10:06:36.540221] [0x00007f03d99ae780] [debug] single instance: undefined. other params: prusa-slicer;--loglevel=5
[2022-05-10 10:06:36.540225] [0x00007f03d99ae780] [debug] full lock path: /home/maxha/.config/PrusaSlicer/cache/12755476446117811484.lock
[2022-05-10 10:06:36.540240] [0x00007f03d99ae780] [debug] Creating lockfile.
[2022-05-10 10:06:36.540244] [0x00007f03d99ae780] [info] Instance check: Another instance not found or single-instance not set.
[2022-05-10 10:06:36.571767] [0x00007f03d99ae780] [trace] Switching wxLocales to en_US
[1] 5811 segmentation fault (core dumped) prusa-slicer --loglevel=5
I had the same problem and solved it by adding the en_GB local. It is done by running sudo dpkg-reconfigure locales selecting the en_GB the default local can be any. Hope that helps
@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: user: prusaslicer password: slicer
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. Running the build you posted was successful - No crash! Thanks for fixing
Thanks for the testing. The fix will be included in 2.6 release.
Sorry for the delayed reply.
The build you provided didn't initially work, however after running lcoale-gen
for the millionth time it suddenly worked, and now the repo build works as well. My guess is I somehow misconfigured my locale settings, but it seems to be fixed now so I'll close this issue.
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 Segmentation fault
with the latest version on Arch Linux PrusaSlicer-2.4.2+UNKNOWN
and the build provided by @lukasmatena worked out of the box.
I can confirm to.
Backtrace of the latest version in the Arch Repos PrusaSlicer-2.4.2+UNKNOWN
.
0x00007ffff54a2d45 in ?? () from /usr/lib/libwx_baseu-3.2.so.0
(gdb) bt
#0 0x00007ffff54a2d45 in () at /usr/lib/libwx_baseu-3.2.so.0
#1 0x00007ffff554d37b in wxTranslations::SetLanguage(wxLanguage) ()
at /usr/lib/libwx_baseu-3.2.so.0
#2 0x0000555555c57284 in ()
#3 0x0000555555c581e8 in ()
#4 0x0000555555c42c90 in ()
#5 0x00007ffff550efe2 in wxEntry(int&, wchar_t**) () at /usr/lib/libwx_baseu-3.2.so.0
#6 0x0000555555c48d68 in ()
#7 0x000055555581f2d6 in ()
#8 0x00005555557bb305 in ()
#9 0x00007ffff3a29290 in () at /usr/lib/libc.so.6
#10 0x00007ffff3a2934a in __libc_start_main () at /usr/lib/libc.so.6
#11 0x0000555555805315 in ()
@feiticeir0 Thanks. Can you be more specific? Which version does not work and what appimage is working fine?
Hi @maggick ! Sorry for not posting that info.
The version that gives a segmentation fault is prusa-slicer 2.4.2-6
.
With gdb, I get:
Reading symbols from prusa-slicer...
(No debugging symbols found in prusa-slicer)
(gdb) run
Starting program: /usr/bin/prusa-slicer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffef5e3640 (LWP 1653)]
[New Thread 0x7fffeede2640 (LWP 1654)]
[New Thread 0x7fffee5e1640 (LWP 1655)]
[New Thread 0x7fffedde0640 (LWP 1656)]
[New Thread 0x7fffed0ef640 (LWP 1657)]
[New Thread 0x7fffec8ee640 (LWP 1658)]
Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
0x00007ffff54a2d45 in ?? () from /usr/lib/libwx_baseu-3.2.so.0
The appimage that works fine is PrusaSlicer-2.4.2+1-lm-languages-crash-linux-x64-GTK3-gec6192a-202205260856.AppImage
Thank you !
Same problem, gdb with debuginfod enabled:
(gdb) run
Starting program: /usr/bin/prusa-slicer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffef5bf640 (LWP 211636)]
[New Thread 0x7fffeedbe640 (LWP 211637)]
[New Thread 0x7fffee5bd640 (LWP 211638)]
[New Thread 0x7fffeddbc640 (LWP 211639)]
[New Thread 0x7fffed1ff640 (LWP 211640)]
[New Thread 0x7fffec9fe640 (LWP 211641)]
Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign (this=0x0, __str=L"") at /usr/include/c++/12.1.0/bits/basic_string.tcc:279
279 const size_type __capacity = capacity();
(gdb) bt
#0 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)
(this=0x0, __str=L"") at /usr/include/c++/12.1.0/bits/basic_string.tcc:279
#1 0x00007ffff554d37b in wxTranslations::SetLanguage(wxLanguage) (this=0x0, lang=<optimized out>) at /usr/src/debug/wxWidgets-3.2.0/src/common/translation.cpp:1384
#2 0x0000555555c57284 in ()
#3 0x0000555555c581e8 in ()
#4 0x0000555555c42c90 in ()
#5 0x00007ffff550efe2 in wxEntry(int&, wchar_t**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/wxWidgets-3.2.0/src/common/init.cpp:487
#6 0x0000555555c48d68 in ()
#7 0x000055555581f2d6 in ()
#8 0x00005555557bb305 in ()
#9 0x00007ffff3a29290 in __libc_start_call_main (main=main@entry=0x5555557bb240, argc=argc@entry=1, argv=argv@entry=0x7fffffffd368) at ../sysdeps/nptl/libc_start_call_main.h:58
#10 0x00007ffff3a2934a in __libc_start_main_impl (main=0x5555557bb240, argc=1, argv=0x7fffffffd368, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd358)
at ../csu/libc-start.c:389
#11 0x0000555555805315 in ()
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 SetLanguage
already. It is probably fixed already in that branch, but the testing and fixing of other smaller bugs is still a work in progress. And it will be released when we think it's ready, not when someone else decides that a different library version than we tested should be used.
@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):
prusa3d/wxWidgets:wx3.1.4-patched
, links statically.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 ys_wx317_master
, which is an attempt to support 3.1.7, but it is mostly untested.
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 (wx3.1.4-patched
), so this is your first option. I’m going to switch to that for now, and we will see how things go with 2.6.0 later on. Normally we are supposed to compile against system dependencies, but we allow exceptions when they are not other sensible options. ;)
@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. OK, I'll read the PKGCONFIG of the (official) archilunx package (and stop spamming the upstream devs here ^^').
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: c3bdf2fc2, while the AppImage works well.
Here the git master traceback:
LANG=en_GB gdb prusa-slicer-git
Reading symbols from prusa-slicer-git...
Reading symbols from /usr/lib/debug/usr/bin/prusa-slicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64.debug...
(gdb) run
Starting program: /usr/bin/prusa-slicer-git
This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.opensuse.org/
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading 0.67 MB separate debug info for /lib64/libqhull_r.so.8.0
Downloading 0.02 MB separate debug info for /home/linus/.cache/debuginfod_client/5984962b20113ba09a3a293f90516f06d50ec4fd/debuginfo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 1173]
[New Thread 0x7ffff22286c0 (LWP 1174)]
[New Thread 0x7ffff1a276c0 (LWP 1175)]
Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign (this=this@entry=0x0, __str=L"") at /usr/src/debug/gcc12-12.1.1+git372-1.1.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/basic_string.tcc:279
279 const size_type __capacity = capacity();
Missing separate debuginfos, use: zypper install libopenvdb9_0-debuginfo-9.0.0-34.20.x86_64
(gdb) bt
#0 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) (this=this@entry=0x0, __str=L"")
at /usr/src/debug/gcc12-12.1.1+git372-1.1.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/basic_string.tcc:279
#1 0x00007ffff5939fda in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) (__str=L"", this=0x0) at /usr/include/c++/12/bits/basic_string.h:1539
#2 0x00007ffff593b1f6 in wxTranslations::SetLanguage(wxLanguage) (this=0x0, lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384
#3 0x0000555555b60fcb in Slic3r::GUI::GUI_App::load_language(wxString, bool) (this=0x5555565e8700, language=..., initial=<optimized out>)
at /usr/src/debug/PrusaSlicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64/src/slic3r/GUI/GUI_App.cpp:2092
#4 0x0000555555b61dfd in Slic3r::GUI::GUI_App::on_init_inner() (this=0x5555565e8700)
at /usr/src/debug/PrusaSlicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64/src/slic3r/GUI/GUI_App.cpp:1106
#5 0x0000555555b491ac in Slic3r::GUI::GUI_App::OnInit() (this=<optimized out>)
at /usr/src/debug/PrusaSlicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64/src/slic3r/GUI/GUI_App.cpp:1048
#6 wxAppConsoleBase::CallOnInit() (this=<optimized out>) at /usr/include/wx-3.2/wx/app.h:93
#7 0x00007ffff590680a in wxEntry(int&, wchar_t**) (argc=<optimized out>, argv=<optimized out>) at ./src/common/init.cpp:487
#8 0x0000555555b555b5 in Slic3r::GUI::GUI_Run(Slic3r::GUI::GUI_InitParams&) (params=...)
at /usr/src/debug/PrusaSlicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64/src/slic3r/GUI/GUI_Init.cpp:56
#9 0x00005555557c3a10 in Slic3r::CLI::run(int, char**) (this=0x7fffffffd450, argc=1, argv=0x7fffffffd688)
at /usr/src/debug/PrusaSlicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64/src/PrusaSlicer.cpp:616
#10 0x0000555555768371 in main(int, char**) (argc=<optimized out>, argv=<optimized out>)
at /usr/src/debug/PrusaSlicer-git-2.5.0~0.20220825T224403.c3bdf2fc2-0.x86_64/src/PrusaSlicer.cpp:875
LANG=en_GB.UTF-8 prusa-slicer-git --loglevel=5
[2022-08-31 21:33:42.356050] [0x00007fad1d4338c0] [trace] App updater default download path: "/home/linus/Downloads"
[2022-08-31 21:33:42.356100] [0x00007fad1d4338c0] [debug] full path: 9218652474371708363
[2022-08-31 21:33:42.356109] [0x00007fad1d4338c0] [debug] single instance: undefined. other params: prusa-slicer-git;--loglevel=5
[2022-08-31 21:33:42.356115] [0x00007fad1d4338c0] [debug] full lock path: /home/linus/.config/PrusaSlicer-alpha/cache/9218652474371708363.lock
[2022-08-31 21:33:42.356132] [0x00007fad1d4338c0] [debug] Creating lockfile.
[2022-08-31 21:33:42.356138] [0x00007fad1d4338c0] [info] Instance check: Another instance not found or single-instance not set.
[2022-08-31 21:33:42.400664] [0x00007fad1d4338c0] [trace] System language detected (user locales and such): en_GB
Speicherzugriffsfehler (Speicherabzug geschrieben)
prusa-slicer-git --loglevel=5
[2022-08-31 21:34:06.412314] [0x00007f8f128488c0] [trace] App updater default download path: "/home/linus/Downloads"
[2022-08-31 21:34:06.412360] [0x00007f8f128488c0] [debug] full path: 9218652474371708363
[2022-08-31 21:34:06.412368] [0x00007f8f128488c0] [debug] single instance: undefined. other params: prusa-slicer-git;--loglevel=5
[2022-08-31 21:34:06.412374] [0x00007f8f128488c0] [debug] full lock path: /home/linus/.config/PrusaSlicer-alpha/cache/9218652474371708363.lock
[2022-08-31 21:34:06.412390] [0x00007f8f128488c0] [debug] Creating lockfile.
[2022-08-31 21:34:06.412396] [0x00007f8f128488c0] [info] Instance check: Another instance not found or single-instance not set.
[2022-08-31 21:34:06.461110] [0x00007f8f128488c0] [trace] System language detected (user locales and such): de_DE
Speicherzugriffsfehler (Speicherabzug geschrieben)
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):
LANG=C gdb prusa-slicer
Reading symbols from prusa-slicer...
Reading symbols from /usr/lib/debug/usr/bin/prusa-slicer-2.4.2-3.3.x86_64.debug...
(gdb) set args --loglevel=5
(gdb) run
Starting program: /usr/bin/prusa-slicer --loglevel=5
This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.opensuse.org/
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[2022-08-31 21:52:38.229353] [0x00007ffff1ede8c0] [debug] full path: 7284294308871141722
[2022-08-31 21:52:38.229373] [0x00007ffff1ede8c0] [debug] single instance: undefined. other params: /usr/bin/prusa-slicer;--loglevel=5
[2022-08-31 21:52:38.229380] [0x00007ffff1ede8c0] [debug] full lock path: /home/linus/.config/PrusaSlicer/cache/7284294308871141722.lock
[2022-08-31 21:52:38.229395] [0x00007ffff1ede8c0] [debug] Creating lockfile.
[2022-08-31 21:52:38.229400] [0x00007ffff1ede8c0] [info] Instance check: Another instance not found or single-instance not set.
[New Thread 0x7ffff1df06c0 (LWP 2657)]
[New Thread 0x7ffff15ef6c0 (LWP 2658)]
[2022-08-31 21:52:38.306166] [0x00007ffff1ede8c0] [trace] System language detected (user locales and such): en_US
Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign (this=this@entry=0x0, __str=L"") at /usr/src/debug/gcc12-12.1.1+git372-1.1.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/basic_string.tcc:279
279 const size_type __capacity = capacity();
(gdb) bt
#0 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) (this=this@entry=0x0, __str=L"")
at /usr/src/debug/gcc12-12.1.1+git372-1.1.x86_64/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/basic_string.tcc:279
#1 0x00007ffff5739fda in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) (__str=L"", this=0x0) at /usr/include/c++/12/bits/basic_string.h:1539
#2 0x00007ffff573b1f6 in wxTranslations::SetLanguage(wxLanguage) (this=0x0, lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384
#3 0x0000555555b53480 in Slic3r::GUI::GUI_App::load_language(wxString, bool) (this=0x555556626280, language=..., initial=<optimized out>)
at /usr/src/debug/PrusaSlicer-2.4.2-3.3.x86_64/src/slic3r/GUI/GUI_App.cpp:2078
#4 0x0000555555b5432f in Slic3r::GUI::GUI_App::on_init_inner() (this=0x555556626280) at /usr/src/debug/PrusaSlicer-2.4.2-3.3.x86_64/src/slic3r/GUI/GUI_App.cpp:1092
#5 0x0000555555b4299c in Slic3r::GUI::GUI_App::OnInit() (this=<optimized out>) at /usr/src/debug/PrusaSlicer-2.4.2-3.3.x86_64/src/slic3r/GUI/GUI_App.cpp:1034
#6 wxAppConsoleBase::CallOnInit() (this=<optimized out>) at /usr/include/wx-3.2/wx/app.h:93
#7 0x00007ffff570680a in wxEntry(int&, wchar_t**) (argc=<optimized out>, argv=<optimized out>) at ./src/common/init.cpp:487
#8 0x0000555555b46f55 in Slic3r::GUI::GUI_Run(Slic3r::GUI::GUI_InitParams&) (params=...) at /usr/src/debug/PrusaSlicer-2.4.2-3.3.x86_64/src/slic3r/GUI/GUI_Init.cpp:54
#9 0x00005555557c77c3 in Slic3r::CLI::run(int, char**) (this=0x7fffffffd450, argc=2, argv=0x7fffffffd688) at /usr/src/debug/PrusaSlicer-2.4.2-3.3.x86_64/src/PrusaSlicer.cpp:618
#10 0x000055555576c041 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/PrusaSlicer-2.4.2-3.3.x86_64/src/PrusaSlicer.cpp:844
Let me know, if I can provide any additional information!
@frispete There are two issues mixed in this thread:
(gdb) bt
#0 std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find(wchar_t, unsigned long) const (this=0x8, __c=95 L'_', __pos=0)
at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:1247
#1 0x0000000001c574ef in wxString::Find(wxUniChar, bool) const ()
#2 0x0000000001c576f4 in wxString::AfterFirst(wxUniChar) const ()
#3 0x0000000000b7e6b6 in Slic3r::GUI::GUI_App::load_language(wxString, bool) ()
which I attempted to fix with commit https://github.com/prusa3d/PrusaSlicer/commit/ec6192a90dca0e6142ba590aa0e7456489915199 .
(gdb) bt
#0 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)
(this=0x0, __str=L"") at /usr/include/c++/12.1.0/bits/basic_string.tcc:279
#1 0x00007ffff554d37b in wxTranslations::SetLanguage(wxLanguage) (this=0x0, lang=<optimized out>) at /usr/src/debug/wxWidgets-3.2.0/src/common/translation.cpp:1384
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 https://github.com/prusa3d/PrusaSlicer/issues/8299#issuecomment-1192467381. 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áš,
@frispete There are two issues mixed in this thread:
[...]
The second issue with the backtrace leading into wxWidgets:
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 static wxTranslations * Get ()
.
Applying this patch fixed it for me:
$ cat PrusaSlicer-fix-wxTranslation-crash.diff
diff --git a/src/slic3r/GUI/GUI_App.cpp b/src/slic3r/GUI/GUI_App.cpp
index 9a4921a84..7ea052f83 100644
--- a/src/slic3r/GUI/GUI_App.cpp
+++ b/src/slic3r/GUI/GUI_App.cpp
@@ -2089,7 +2089,9 @@ bool GUI_App::load_language(wxString language, bool initial)
// Allocating a temporary locale will switch the default wxTranslations to its internal wxTranslations instance.
wxLocale temp_locale;
// Set the current translation's language to default, otherwise GetBestTranslation() may not work (see the wxWidgets source code).
- wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);
+ wxTranslations *wx_trp = wxTranslations::Get();
+ if (wx_trp) {
+ wx_trp->SetLanguage(wxLANGUAGE_DEFAULT);
// Let the wxFileTranslationsLoader enumerate all translation dictionaries for PrusaSlicer
// and try to match them with the system specific "preferred languages".
// There seems to be a support for that on Windows and OSX, while on Linuxes the code just returns wxLocale::GetSystemLanguage().
@@ -2100,6 +2102,7 @@ bool GUI_App::load_language(wxString language, bool initial)
m_language_info_best = wxLocale::FindLanguageInfo(best_language);
BOOST_LOG_TRIVIAL(trace) << boost::format("Best translation language detected (may be different from user locales): %1%") % m_language_info_best->CanonicalName.ToUTF8().data();
}
+ }
#ifdef __linux__
wxString lc_all;
if (wxGetEnv("LC_ALL", &lc_all) && ! lc_all.IsEmpty()) {
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 SetLanguage
crash should be this:
// Allocating a temporary locale will switch the default wxTranslations to its internal wxTranslations instance.
wxLocale temp_locale;
+ #ifdef __WXOSX__
+ // ysFIXME - temporary workaround till it isn't fixed in wxWidgets:
+ // Use English as an initial language, because of under OSX it try to load "inappropriate" language for wxLANGUAGE_DEFAULT.
+ // For example in our case it's trying to load "en_CZ" and as a result PrusaSlicer catch warning message.
+ // But wxWidgets guys work on it.
+ temp_locale.Init(wxLANGUAGE_ENGLISH);
+ #else
+ temp_locale.Init();
+ #endif // __WXOSX__
// Set the current translation's language to default, otherwise GetBestTranslation() may not work (see the wxWidgets source code).
wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);
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 Init()
call.
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 :wink:
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!
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.
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.
How many combinations of hardware, operating systems, drivers etc. do you actually test?
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.
Description of the bug
When trying to launch prusa-slicer I get the following error:
[1] 101694 segmentation fault (core dumped) prusa-slicer
This happened on every version I triedProject 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