Opened 3 years ago

Closed 2 years ago

#12909 closed Bug Report - Crash (Fixed)

mythfrontend crashes with SIGSEGV in code called from QImage::Load

Reported by: roger@… Owned by: stuartm
Priority: major Milestone: 29.0
Component: MythTV - User Interface Library Version: 0.28.0
Severity: high Keywords:
Cc: Ticket locked: no


mythfrontend randomly crashes on startup when a lot of images are being loaded into the image cache. Analysis of the crash shows that QImage::Load is being called on multiple threads. The QImage class is specifically marked in the Qt docs as re-entrant but not thread-safe.

The crashes usually occur in QFactoryLoader::instance but can occur elsewhere in QT. The common factor is they all root at ImageLoader::LoadImage? in mythuiimage.cpp.

Here is a sample stack trace. The SIGSEGV occurs when qt tries to call a plugin that has been unloaded from memory.

(gdb) bt
#0  0x00007f90f8142d50 in ?? ()
#1  0x00007f91123f8375 in QFactoryLoader::instance (
    this=this@entry=0x7f9112ea5240 <_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder>, index=index@entry=0) at plugin/qfactoryloader.cpp:259
#2  0x00007f9112ab059d in createReadHandlerHelper (device=0x7f90b800e9c0, 
    format=..., autoDetectImageFormat=<optimized out>, 
    ignoresFormatAndExtension=<optimized out>) at image/qimagereader.cpp:318
#3  0x00007f9112ab1449 in QImageReaderPrivate::initHandler (
    this=0x7f90b8042540) at image/qimagereader.cpp:617
#4  0x00007f9112ab2782 in QImageReader::read (this=0x7f90bfffe500, 
    image=0x7f90bfffe4a0) at image/qimagereader.cpp:1276
#5  0x00007f9112ab2814 in QImageReader::read (this=this@entry=0x7f90bfffe500)
    at image/qimagereader.cpp:1244
#6  0x00007f9112a950e3 in QImage::load (this=0x7f90b800eec0, fileName=..., 
    format=<optimized out>) at image/qimage.cpp:3206
#7  0x00007f91141e1b44 in MythImage::Load (this=0x7f90b800e920, filename=...)
    at mythimage.cpp:364
#8  0x00007f9114209b13 in MythUIHelper::LoadCacheImage (this=0x1bc5050, 
    srcfile=..., label=..., painter=0x1c283c0, cacheMode=kCacheNormal)
    at mythuihelper.cpp:1672 (This is slightly off because I put some debug in}
#9  0x00007f911422a9fc in ImageLoader::LoadImage (painter=0x1c283c0, 
    imProps=..., cacheMode=kCacheNormal, parent=0x20e7360, 
    aborted=@0x7f90bfffeb4f: false, imageReader=0x0) at mythuiimage.cpp:273
#10 0x00007f911422c255 in ImageLoadThread::run (this=0x20e7a60)
    at mythuiimage.cpp:553
#11 0x00007f9114646961 in MPoolThread::run (this=0x1ebe220)
    at mthreadpool.cpp:140
#12 0x00007f9114642e70 in MThreadInternal::run (this=0x1cd8210)
    at mthread.cpp:79
#13 0x00007f911222b84e in QThreadPrivate::start (arg=0x1cd8210)
    at thread/qthread_unix.cpp:331
#14 0x00007f9111f706fa in start_thread (arg=0x7f90bffff700)
    at pthread_create.c:333
#15 0x00007f9111405b5d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I can usually get this crash within four or five reboots and autostarts on my shuttle frontend box. Putting a 60 second delay in the mythfrontend wrapper script alleviates it considerably.

This problem seems to have been around for some time. There are one or two expired tickets on the mythbuntu bug tracker that seem to have similar symptoms.

Change History (4)

comment:1 Changed 2 years ago by Jonatan Lindblad

I don't think MythTV is at fault here. A possible Qt bug is which has been fixed in 5.9.0.

comment:2 Changed 2 years ago by Peter Bennett

There is a way to disable the threaded image load. You can set environment variable DISABLETHREADEDMYTHUIIMAGE=1 before running mythfrontend. I don't know how well that works or how much impact it will have on performance.

I have previously seen a problem in a specific case where images were deleted while they were still being loaded in another thread. I don't know if that could be the problem here.

comment:3 Changed 2 years ago by Roger James <roger@…>

I think you can close this as invalid now. The crah only occured at mythfrontend startup when a huge number of threads wre displatched to load images into the cache. I put some extra locking to fix this locally in 0.28. However I have been running builds from the latest head (29.0 onwards) for some time now without the fix in it and the problem has not reappeared.


comment:4 Changed 2 years ago by Stuart Auchterlonie

Milestone: unknown29.0
Resolution: Fixed
Status: newclosed
Note: See TracTickets for help on using tickets.