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: yianniv <yiannividalis@…> 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)

gdb.txt.gz (19.8 KB) - added by yianniv <yiannividalis@…> 8 years ago.
backtrace log

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by yianniv <yiannividalis@…>

Attachment: gdb.txt.gz added

backtrace log

comment:1 Changed 8 years ago by yianniv <yiannividalis@…>

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 beirdo

Owner: set to danielk
Status: newassigned

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 yianniv <yiannividalis@…>

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 beirdo

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 yianniv <yiannividalis@…>

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 Github

Milestone: unknown0.25
Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.