search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.71k stars 1.93k forks source link

Segfault on arch linux #8299

Closed maxhambraeus closed 2 years ago

maxhambraeus commented 2 years ago

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

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

maxhambraeus commented 2 years ago

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.

lukasmatena commented 2 years ago

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

maxhambraeus commented 2 years ago 
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 ()
lukasmatena commented 2 years ago

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?

maxhambraeus commented 2 years ago

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
sbraitbart commented 2 years ago

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

lukasmatena commented 2 years ago

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

lukasmatena commented 2 years ago

@maxhambraeus If you are still able to reproduce the issue, would you please mind testing the build I provided in my previous post? Thanks.

sbraitbart commented 2 years ago

I reproduced the issue by removing the GB from locals. Running the build you posted was successful - No crash! Thanks for fixing

lukasmatena commented 2 years ago

Thanks for the testing. The fix will be included in 2.6 release.

maxhambraeus commented 2 years ago

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.

feiticeir0 commented 2 years ago

I'm having the same issue. Added en_GB to locale and run locale-gen... Still crashing - The appimage is working fine !

lukasmatena commented 2 years ago

@feiticeir0 Thanks. Can you be more specific? Which version does not work and what appimage is working fine?

maggick commented 2 years ago

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.

niklasarnitz commented 2 years ago

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 commented 2 years ago

@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 !

lodriguez commented 2 years ago

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  ()
lukasmatena commented 2 years ago

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.

ArchangeGabriel commented 2 years ago

@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?

lukasmatena commented 2 years ago

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

ArchangeGabriel commented 2 years ago

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

Salamandar commented 2 years ago

@ArchangeGabriel the cleanest solution I see is writing a wxwidgets-gtk3-31 package (in the AUR) to build prusa-slicer against.

ArchangeGabriel commented 2 years ago

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

Salamandar commented 2 years ago

@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 ^^').

frispete commented 2 years ago

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!

lukasmatena commented 2 years ago

@frispete There are two issues mixed in this thread:

  1. the original issue from @maxhambraeus with this backtrace 
    (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 .

  1. The second issue with the backtrace leading into wxWidgets: 
    (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.

frispete commented 2 years ago

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?

lukasmatena commented 2 years ago

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

frispete commented 2 years ago

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!

frispete commented 2 years ago

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!

bubnikv commented 2 years ago

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

frispete commented 2 years ago

@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!

StefanBruens commented 2 years ago

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?

lukasmatena commented 1 year ago

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