In this commit [1] upstream thoughtfully inflicted an always-on auto-update checker on all non-windows users that fires in the background shortly after startup, apparently fails at random to connect to its server, which then sends a timeout sigalrm to libcurl, which gets confused due to thread unsafety and explodes in a scary way. Below is the gdb backtrace - the app dies with no error message or warning at all (not even in dmesg, because it's not a segfault, fortify-source is killing it): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff6bacf99 in __GI_abort () at abort.c:89 #2 0x00007ffff6bee51f in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff6cf3766 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff6c84ba7 in __GI___fortify_fail (msg=0x7ffff6cf3725 <longjmp_msg> "longjmp causes uninitialized stack frame") at fortify_fail.c:30 #4 0x00007ffff6c849dd in ____longjmp_chk () at ../sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:100 #5 0x00007ffff6c8493b in __longjmp_chk (env=0x3253c6c280, val=<optimized out>) at ../setjmp/longjmp.c:38 #6 0x00007ffff79703f5 in alarmfunc (sig=<optimized out>) at /var/tmp/portage/net-misc/curl-7.55.1/work/curl-7.55.1/lib/hostip.c:540 #7 <signal handler called> #8 0x00007ffff6c6544d in poll () at ../sysdeps/unix/syscall-template.S:84 #9 0x00000035ea04bd7e in ?? () from /usr/lib64/libglib-2.0.so.0 #10 0x00000035ea04beac in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #11 0x00000035d4a987bf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #12 0x00000035d4a47c9a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #13 0x00000035d4a4fa9c in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5 #14 0x00000000004739d7 in main () I know adding a USE-dep would be the most technically correct fix, but I think it'd be better if that whole misfeature is patched to an "#if 0" until upstream redoes it properly - and makes the off switch in the UI actually work! [1]: https://github.com/jp9000/obs-studio/commit/8b315186a724f3af59163196db79080ffd26dfcb
Thank you for the report! I had not noticed this yet myself, at all. For now, I added a patch in https://github.com/gentoo/gentoo/pull/5642 that seems to prevent the crash for me.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82e3d3b953257976714cc144dcd960471caa42a7 commit 82e3d3b953257976714cc144dcd960471caa42a7 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2017-10-09 02:16:21 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2017-10-11 21:04:18 +0000 media-video/obs-studio: add a patch to fix a crash related to net-misc/curl. Upstream Pull Request: https://github.com/jp9000/obs-studio/pull/1038 Closes: https://bugs.gentoo.org/633596 Closes: https://github.com/gentoo/gentoo/pull/564 Package-Manager: Portage-2.3.11, Repoman-2.3.3 .../files/obs-studio-20.0.1-fix-curl-crash.patch | 46 ++++++++ media-video/obs-studio/obs-studio-20.0.1-r1.ebuild | 121 +++++++++++++++++++++ 2 files changed, 167 insertions(+)
