Opened 8 years ago
Closed 8 years ago
#9972 closed Bug Report - General (fixed)
backend, frontend segfault with /usr/lib64/libQtCore.so.4
| Reported by: | Owned by: | danielk | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.25 |
| Component: | MythTV - General | Version: | Master Head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
I upgraded from e03fc09 to e433387b141 and cannot start either mythbackend or frontend on my MB system. They segfault. The SB seems to be unaffected.
Both systems run opensuse 11.4, and the offending file, /usr/lib64/libQtCore.so.4, is: MB: libqt4-4.7.2-161.1.x86_64 SB: libqt4-4.7.3-181.1.x86_64
Should I just upgrade libqt4? (version 4.7.3-186 is available now) I cannot even execute mythfrontend --help From gdb.txt: Program received signal SIGSEGV, Segmentation fault. 0x00007fffef1999bc in QMutex::lock() () from /usr/lib64/libQtCore.so.4
Attachments (1)
Change History (7)
Changed 8 years ago by
| Attachment: | gdb.txt.gz added |
|---|
comment:1 Changed 8 years ago by
I am currently away from the pcs, connected through ssh. It seems that the mythfrontend is segfaulting on the SB as well (tested with DISPLAY=:0 mythfrontend)
comment:2 Changed 8 years ago by
| Owner: | set to danielk |
|---|---|
| Status: | new → assigned |
No. This is not a Qt bug.
I am going to checkin my preliminary fix for it, and danielk can redo it/change it if he wishes. This will at least get people through the fun.
comment:3 Changed 8 years ago by
I apologise for posting in installments, but I am not at home at the moment.
The gdb comment of the frontend in the SB is:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffed0249bc in QMutex::lock (this=0x7ffff5cc4578) at thread/qmutex.cpp:151
151 thread/qmutex.cpp: No such file or folder.
in thread/qmutex.cpp
comment:4 Changed 8 years ago by
Sorry, forgot to put Refs #9972 in the commit message before pushing. My preliminary fix is in 7b36b04a634aa3ef3426 on master.
comment:5 Changed 8 years ago by
Thank you Beirdo, both BEs and FEs start now. If nobody else has a similar problem, please close this ticket as fixed.
Yianni.
comment:6 Changed 8 years ago by
| Milestone: | unknown → 0.25 |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
Fixes #9972. Apply the construct on first use idiom to two previously staticaly initialized threads.
C++ initializes statics in a strict order within a compilation unit, but across compilation units the order is random.
This is a problem when you statically initialize an MThread because you may initialize it before the static MThread debugging variables are statically initialized. i.e. mythsocket.o or logging.o may be initialized before mthread.o
It's possible to work around this using compiler attributes, but a cleaner solution is to use the construct-on-first-use idiom as it will work correctly on all systems.
This also adds a warning to the mthread.h doxygen doct to not to statically initialize threads.
Branch: master Changeset: f4ba7827e165672ed8c0c901b50243443f5f203d
backtrace log