openmw.org

OpenMW Forum
https://forum.openmw.org/

Segmentation fault when running launcher

https://forum.openmw.org/viewtopic.php?t=5236

Page 1 of 1

Segmentation fault when running launcher

Posted: 17 Jun 2018, 07:50
by heilkitty
How can one debug this? I guess, my launcher.cfg done got messed up somehow, after deleting it, the launcher ran as per usual, autogenerated content list and stuff.

Re: Segmentation fault when running launcher

Posted: 17 Jun 2018, 11:14
by Zini
Running under the debugger and getting a stack backtrace is usually the first step.

Re: Segmentation fault when running launcher

Posted: 17 Jun 2018, 11:33
by drummyfish
If you've got the project compiled with debug symbols, valgrind can tell you where and why the program crashed.

Re: Segmentation fault when running launcher

Posted: 17 Jun 2018, 11:51
by heilkitty
What are cmake options to build with debug symbols?

Re: Segmentation fault when running launcher

Posted: 17 Jun 2018, 12:48
by psi29a
CMAKE_BUILD_TYPE and the options are: Debug Release RelWithDebInfo MinSizeRel
cmake -DCMAKE_BUILD_TYPE=Debug ../openmw

Re: Segmentation fault when running launcher

Posted: 17 Jun 2018, 14:04
by heilkitty
So, would this valgrind output be sufficient for a bug report?

Code: Select all

$ valgrind ./openmw-launcher       
==26942== Memcheck, a memory error detector
==26942== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26942== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==26942== Command: ./openmw-launcher
==26942== 
Loading config file: launcher.cfg 
Loading config file: /home/heilkitty/.config/openmw/launcher.cfg 
Loading config file: /home/heilkitty/.config/openmw/openmw.cfg 
Loading config file: /usr/local/etc/openmw/openmw.cfg 
QFile::setFileName: File (/home/heilkitty/.config/openmw/openmw.cfg) is already opened
Loading config file: ./openmw.cfg 
Loading config file: /home/heilkitty/.config/openmw/openmw.cfg 
Loading settings file: ./settings-default.cfg
Loading settings file: /home/heilkitty/.config/openmw/settings.cfg
The current profile is:  "2017-07-25T20:41:51" 
==26942== Use of uninitialised value of size 8
==26942==    at 0x66C4D44: pthread_mutex_lock (pthread_mutex_lock.c:67)
==26942==    by 0x9090BF9: XrmQGetResource (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==26942==    by 0x906CF85: XGetDefault (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==26942==    by 0xA1FE059: _XcursorGetDisplayInfo (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0xA1FE148: XcursorGetDefaultSize (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0xA200574: XcursorLibraryLoadCursor (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0x508BDCA: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x508C4B4: QCursor::handle() const (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x509878F: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x509DAE7: QWidgetPrivate::create_sys(unsigned long, bool, bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x504C39A: QWidget::create(unsigned long, bool, bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x5054AD6: QWidget::setVisible(bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942== 
==26942== Invalid read of size 4
==26942==    at 0x66C4D44: pthread_mutex_lock (pthread_mutex_lock.c:67)
==26942==    by 0x9090BF9: XrmQGetResource (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==26942==    by 0x906CF85: XGetDefault (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==26942==    by 0xA1FE059: _XcursorGetDisplayInfo (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0xA1FE148: XcursorGetDefaultSize (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0xA200574: XcursorLibraryLoadCursor (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0x508BDCA: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x508C4B4: QCursor::handle() const (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x509878F: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x509DAE7: QWidgetPrivate::create_sys(unsigned long, bool, bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x504C39A: QWidget::create(unsigned long, bool, bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x5054AD6: QWidget::setVisible(bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==26942== 
==26942== 
==26942== Process terminating with default action of signal 11 (SIGSEGV)
==26942==  Access not within mapped region at address 0x10
==26942==    at 0x66C4D44: pthread_mutex_lock (pthread_mutex_lock.c:67)
==26942==    by 0x9090BF9: XrmQGetResource (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==26942==    by 0x906CF85: XGetDefault (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==26942==    by 0xA1FE059: _XcursorGetDisplayInfo (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0xA1FE148: XcursorGetDefaultSize (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0xA200574: XcursorLibraryLoadCursor (in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==26942==    by 0x508BDCA: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x508C4B4: QCursor::handle() const (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x509878F: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x509DAE7: QWidgetPrivate::create_sys(unsigned long, bool, bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x504C39A: QWidget::create(unsigned long, bool, bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==    by 0x5054AD6: QWidget::setVisible(bool) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.7)
==26942==  If you believe this happened as a result of a stack
==26942==  overflow in your program's main thread (unlikely but
==26942==  possible), you can try to increase the size of the
==26942==  main thread stack using the --main-stacksize= flag.
==26942==  The main thread stack size used in this run was 8388608.
==26942== 
==26942== HEAP SUMMARY:
==26942==     in use at exit: 4,086,499 bytes in 34,911 blocks
==26942==   total heap usage: 391,512 allocs, 356,601 frees, 76,728,546 bytes allocated
==26942== 
==26942== LEAK SUMMARY:
==26942==    definitely lost: 13,320 bytes in 166 blocks
==26942==    indirectly lost: 29,700 bytes in 1,234 blocks
==26942==      possibly lost: 543,804 bytes in 7,238 blocks
==26942==    still reachable: 3,499,675 bytes in 26,273 blocks
==26942==                       of which reachable via heuristic:
==26942==                         newarray           : 5,896 bytes in 20 blocks
==26942==                         multipleinheritance: 24 bytes in 1 blocks
==26942==         suppressed: 0 bytes in 0 blocks
==26942== Rerun with --leak-check=full to see details of leaked memory
==26942== 
==26942== For counts of detected and suppressed errors, rerun with: -v
==26942== Use --track-origins=yes to see where uninitialised values come from
==26942== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Re: Segmentation fault when running launcher

Posted: 15 Jul 2018, 07:25
by heilkitty
OK, rebuilt openmw with QT5, launcher works fine now (except for some failed DBus assertions, which are not critical, it seems). I guess, it's another reason to deprecate QT4.

Re: Segmentation fault when running launcher

Posted: 25 Jul 2018, 18:17
by Capostrophic
Breaking Qt4 compatibility in launcher definitely wasn't intended and it's a real issue for me and other people. Launcher doesn't work in k1ll's nightlies either, and getting the launcher broken in 0.45.0 linux release builds will obviously not be good. of course, it won't get to that, but it's better to deal with this issue much earlier than 0.45.0 manages to get into a RC phase.

It's a regression that somehow lived for about a month or even more. Probably because nobody bothered to report it (I thought this issue was specific to my builds). :/

Re: Segmentation fault when running launcher

Posted: 26 Jul 2018, 09:29
by Zini
Do we have an issue filed for this regression? Should be marked as blocker.

Edit: Anyone able to do a bisect on this? Preferably someone who's computer isn't cooking right now? I have CPU idle temps of over 40 °C right now (more than 20°C above normal). Bloody heatwave.

Re: Segmentation fault when running launcher

Posted: 26 Jul 2018, 14:49
by AnyOldName3
Idle above 40° isn't something you need to worry about. Any slightly recent machine will throttle and then turn itself off if it's close to being damaged by overheating. You might see reduced performance under load if you get above about 95°, but your computer is fine with that, and just has a bit of a lazy day where it doesn't work as hard.
All times are UTC+01:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited