bluecube
commented
2 years ago Correction: This does not go away after saving project file
Closed bluecube closed 8 months ago
bluecube
commented
2 years ago Correction: This does not go away after saving project file
bluecube
commented
2 years ago Does not happen in 2.5.0-alpha0 Edit: Actually it does, but less frequently
lukasmatena
commented
2 years ago @bluecube Can you please build PrusaSlicer statically as described in https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Linux%20et%20al.md and check whether the issue is still present? It may be caused by some mismatch between PS and some of the depending library, which may happen because of e.g. different bugs in different versions. Using "kind of weird" build options certainly does not make it easier.
Also, building with debug symbols and providing a backtrace might be useful, but I do not promise that we will actually troubleshoot the issue.
MuninnAndHuginn
commented
2 years ago I am in a similar situation using Gentoo and latest 2.6.0-alpha0. Building via the supplied instructions on the same tag of the repo results in a working version (so far). System Info: PrusaSlicer Version: 2.6.0-alpha0 Build: PrusaSlicer-2.6.0-alpha0+UNKNOWN
Operating System: Unix System Architecture: 64 bit System Version: Linux 5.15.41-gentoo x86_64 Total RAM size [MB]: 33,557MB OpenGL installation GL version: 4.6 (Compatibility Profile) Mesa 22.0.5 Vendor: AMD Renderer: AMD Radeon R9 380 Series (tonga, LLVM 14.0.4, DRM 3.42, 5.15.41-gentoo) GLSL version: 4.60
bluecube
commented
2 years ago For me the static build also works correctly. Unfortunately currently I'm a bit short on time, but I hope I'll manage to try pinpointing the problem this weekend.
thesamesam
commented
2 years ago Had another report downstream in Gentoo: https://bugs.gentoo.org/853973.
Could somebody hitting this grab a backtrace?
PyBonnetainNesterenko
commented
2 years ago Had another report downstream in Gentoo: https://bugs.gentoo.org/853973.
Could somebody hitting this grab a backtrace?
Having this "longjmp" crash systematically. Compiled slicer (on Gentoo) with debug symbols enabled.
Weird.
If running prusa-slicer, crashes "as usual". But when runningn under gdb, everything is okay as far as our tests have gone. We managed to get a few SIGALRM (untrapped signal ?) that crash the slicer, though. Not sure it's the same problem. Here is the backtrace when catching the SIGALRM under gdb.
`Thread 1 "slic3r_main" hit Catchpoint 1 (signal SIGALRM), 0x00007ffff585775f in poll () from /lib64/libc.so.6
(gdb) bt
`
PyBonnetainNesterenko
commented
2 years ago Got one ! Quite difficult to trigger under gdb, but here is the backtrace (hope I did all stuff needed to get useful data) :
` longjmp causes uninitialized stack frame : terminated
[2022-06-26 10:53:44.607625] [0x00007fffdbfff640] [error] Error getting: https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaSlicer.version2: HTTP 0, Timeout was reached:
Connection timeout after 10000 ms
[Error 28]
[2022-06-26 10:53:44.607736] [0x00007fffdbfff640] [error] Downloading PrusaSlicer version file has failed:
Error getting: https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaSlicer.version2: HTTP 0, Timeout was reached:
Connection timeout after 10000 ms
[Error 28]
[2022-06-26 10:53:44.608446] [0x00007ffff1c15640] [error] Error getting: https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaResearch//index.idx: HTTP 0, Timeout was reached:
Connection timeout after 10001 ms
[Error 28]
[Thread 0x7fffdbfff640 (LWP 21704) exited]
Thread 1 "slic3r_main" received signal SIGABRT, Aborted. 0x00007ffff57e442f in ?? () from /lib64/libc.so.6 (gdb) bt
at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLModel.cpp:1117(range={...}, this=0x7fffffff8ac0)
at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLModel.cpp:836at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLModel.cpp:822at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLModel.cpp:779(tex_id=tex_id@entry=8, left=left@entry=-1, right=right@entry=-0.993315518, bottom=bottom@entry=-0.993315518, top=top@entry=-0.866279066, uvs=...)
at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLTexture.cpp:369(this=this@entry=0x555558aa3340, left=left@entry=-1, top=top@entry=-0.856589139, right=-0.814171135, bottom=-1, border_w=border_w@entry=0.00668449234, border_h=border_h@entry=0.00968992244)
at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLToolbar.cpp:1478(this=0x555558aa3340, parent=...)
at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLToolbar.cpp:1763at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLCanvas3D.cpp:6160at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLCanvas3D.cpp:5953at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLCanvas3D.cpp:1755at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLCanvas3D.cpp:2590at /var/tmp/portage/media-gfx/prusaslicer-2.6.0_pre20220620/work/src/slic3r/GUI/GLCanvas3D.cpp:2565--Type
(gdb)
`
thesamesam
commented
2 years ago I think we might need debugging symbols (and ideally sources) for sys-libs/glibc, net-misc/curl, and media-libs/mesa too. Feels weird there's a _fortify_fail in there.
bubnikv
commented
2 years ago It looks to me that the issue is somewhere in graphics driver.
#0 0x00007ffff57e442f in () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/1 0x00007ffff5798a12 in raise () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/2 0x00007ffff578346d in abort () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/3 0x00007ffff57d8788 in () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/4 0x00007ffff5872a52 in __fortify_fail () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/5 0x00007ffff587296d in () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/6 0x00007ffff58728ce in __longjmp_chk () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/7 0x00007ffff707f745 in () at /usr/lib64/libcurl.so.4
https://github.com/prusa3d/PrusaSlicer/issues/8 0x00007ffff5798ab0 in () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/issues/9 0x00007ffff58cfef8 in () at /lib64/libc.so.6
https://github.com/prusa3d/PrusaSlicer/pull/10 0x00007fffbb5707be in () at /usr/lib64/dri/crocus_dri.so
https://github.com/prusa3d/PrusaSlicer/issues/11 0x00007fffbb081002 in () at /usr/lib64/dri/crocus_dri.so
https://github.com/prusa3d/PrusaSlicer/issues/12 0x00007fffbb08190e in () at /usr/lib64/dri/crocus_dri.so
https://github.com/prusa3d/PrusaSlicer/issues/13 0x00007fffbb084fd9 in () at /usr/lib64/dri/crocus_dri.so
https://github.com/prusa3d/PrusaSlicer/issues/14 0x00005555563681c6 in Slic3r::GUI::GLModel::send_to_gpu() (this=0x7fffffff8ac0)The fishy call in this call stack is libcurl.so.4, it should not be called from the GPU driver. Likely the stack trace is not correct due to optimization.[
PyBonnetainNesterenko
commented
2 years ago It looks to me that the issue is somewhere in graphics driver.
The fishy call in this call stack is libcurl.so.4, it should not be called from the GPU driver. Likely the stack trace is not correct due to optimization.[
And
I think we might need debugging symbols (and ideally sources) for sys-libs/glibc, net-misc/curl, and media-libs/mesa too. Feels weird there's a _fortify_fail in there.
I'm far from the « proper » computer for some days. Will look into this (meaning trying to get some useful backtrace) next week.
PyBonnetainNesterenko
commented
2 years ago The fishy call in this call stack is libcurl.so.4, it should not be called from the GPU driver. Likely the stack trace is not correct due to optimization.[
Should I try to recompile stuff with -O0 ?
PyBonnetainNesterenko
commented
2 years ago Hello,
Compile the latest (Gentoo) version of prusaslicer (2.6.0_pre20220620-r1). Got several SIGALRM, and the dreaded "longjump" error. Here is the backtrace.
[2022-07-03 20:56:45.852136] [0x00007ffff1c0b640] [error] Error getting: https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaResearch//index.idx: HTTP 0, Timeout was reached:
Connection timeout after 10000 ms
[Error 28]
[2022-07-03 20:56:45.855102] [0x00007fffa6a01640] [error] Error getting: https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaSlicer.version2: HTTP 0, Timeout was reached:
Connection timeout after 10000 ms
[Error 28]
[2022-07-03 20:56:45.855138] [0x00007fffa6a01640] [error] Downloading PrusaSlicer version file has failed:
Error getting: https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaSlicer.version2: HTTP 0, Timeout was reached:
Connection timeout after 10000 ms
[Error 28]
[Thread 0x7fffa6a01640 (LWP 26509) exited]
longjmp causes uninitialized stack frame : terminated
Thread 1 "slic3r_main" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=
Does not look exactly as previously.
thesamesam
commented
2 years ago So the jump is from a timeout in curl? Huh.
thesamesam
commented
2 years ago emerge -v1p net-misc/curl (to see the flags)? Flipping USE=threads on curl may make a difference. Also, try flipping USE=adns.bubnikv
commented
2 years ago @thesamesam thanks for the investigation.
If it is an issue with libcurl library, does PrusaSlicer compiled with our deps scripts the way we recommend and the way we produce our builds resolve the libcurl issue? Do you have the libcurl issue with out official Linux binary builds?
In case there is no issue with our official binary builds, then I suppose the distro provided libcurl should be patched?
MuninnAndHuginn
commented
2 years ago Original USE flags:
`~ ❯❯❯ emerge -vlp net-misc/curl ⏎
These are the packages that would be merged, in order:
Calculating dependencies... done! [ebuild R ] net-misc/curl-7.83.1::gentoo USE="ftp http2 imap ipv6 openssl pop3 progress-meter smtp ssl tftp -adns -alt-svc -brotli -gnutls -gopher -hsts -idn -kerberos -ldap -mbedtls (-nghttp3) -nss (-quiche) -rtmp -samba -ssh -sslv3 -static-libs -telnet -test -threads -verify-sig -zstd" ABI_X86="(64) -32 (-x32)" CURL_SSL="openssl -gnutls -mbedtls -nss" 0 KiB `
Updated USE flags to add adns (based on curl/fedora reports above: ` env USE="adns" emerge -av net-misc/curl
These are the packages that would be merged, in order:
Calculating dependencies... done! [ebuild R ] net-misc/curl-7.83.1::gentoo USE="adns* ftp http2 imap ipv6 openssl pop3 progress-meter smtp ssl tftp -alt-svc -brotli -gnutls -gopher -hsts -idn -kerberos -ldap -mbedtls (-nghttp3) -nss (-quiche) -rtmp -samba -ssh -sslv3 -static-libs -telnet -test -threads -verify-sig -zstd" ABI_X86="(64) -32 (-x32)" CURL_SSL="openssl -gnutls -mbedtls -nss" 0 KiB `
I am assuming simply recompiling curl with c-ares and trying to run prusa-slicer is enough to test this. It appears to work properly now.
bluecube
commented
2 years ago This problem seems to be fixed downstream in media-gfx/prusaslicer-2.6.0_pre20220601-r2. It still feels like an error that prusaslicer compiles fine with wrongly configured curl and then crashes.
bubnikv
commented
2 years ago @bluecube
You are referencing the following script, right? https://gitweb.gentoo.org/repo/gentoo.git/tree/media-gfx/prusaslicer/prusaslicer-2.6.0_pre20220601-r2.ebuild
If that is so, then I don't see anything PrusaSlicer specific wrt. libcurl. Thus it looks as if the libcurl issue was fixed in gentoo, not in PrusaSlicer, right?
MuninnAndHuginn
commented
2 years ago The change was related to line 32. The addition of the adns requirement for curl. net-misc/curl[adns]
This will require curl with async DNS support in order to compile/install prusaslicer. So I guess more of a dependency specification adjustment than anything.
lukasmatena
commented
8 months ago Closing. If I understand it correctly, there was not a problem in PrusaSlicer.
Description of the bug
When running PrusaSlicer after a new installation, I get frequent crashes with message
*** longjmp causes uninitialized stack frame ***: terminated.This seems to happen only with a fresh installation, before saving a project file for the first time. After I manage to save a project without the slicer crashing, this seems to go away.
This happens with version 2.6.0-alpha0. I've seen this behavior with some older version too (recently), but unfortunately can't say exactly which (2.5?)
I'm using a gentoo ebuild
media-gfx/prusaslicer-2.6.0_pre20220601, together with gentooLTO, so that my build options are probably kind of weird:Project file & How to reproduce
Start PrusaSlicer, wiggle with build platter view, try to open a model ...
Checklist of files included above
Version of PrusaSlicer
2.6.0-alpha0
Operating system
Gentoo Linux + gentooLTO, up to date (2022-06)
Printer model
Heavily modified Ender3