mythbackend segfaults in libQtCore during media scanning

[Jeremy Kerr <jk@…>]

A few minutes after starting mythbackend, it dies with a segfault in libQtCore.

Before the crash, I noticed that the load on mysqld was high; after enabling the mysql's general log, I see that the mythbackend seems to be continually trying one query:

100907 10:42:32   530 Prepare   INSERT INTO upnpmedia (intid, class, itemtype, parentid, itemproperties, filepath, filename, title, coverart) VALUES (?, ?, 'FOLDER', ?, '', ?, ?, ?, ?)
                  530 Reset stmt        
                  530 Execute   INSERT INTO upnpmedia (intid, class, itemtype, parentid, itemproperties, filepath, filename, title, coverart) VALUES (112785, 'VIDEO', 'FOLDER', 112784, '', '/media/network/jk/Soundtracks/', '', '', '')
                  530 Close stmt

:it appears to be crashing while scanning for media; I have both the mythvideo and mythmusic plugins enabled, and they're configured to find content in /media/network.

/media/network/jk/Soundtracks contains one directory, with the name 'π' (ie, \317\200). The (flac) files in this directory all have 'π' as their album name. If I remove this directory, this bug no longer occurs.

I'll attach a backtrace of all threads, but here's the one for the thread that caused the segfault:

#0  0x07a2264c in QString (this=0xb0951158, unicode=0xa98e738e, size=1) at tools/qstring.cpp:971
#1  0x07a22899 in QString::mid (this=0xa98e7730, position=30, n=1) at tools/qstring.cpp:3267
#2  0x07ab3de4 in QFSFileEngine::fileName (this=0xa98e64c8, file=QAbstractFileEngine::BaseName) at io/qfsfileengine_unix.cpp:985
#3  0x07ab4982 in QFSFileEngine::fileFlags (this=0xa98e64c8, type=...) at io/qfsfileengine_unix.cpp:827
#4  0x07a65a52 in QFileInfoPrivate::getFileFlags (this=0xa98e70a0, request=...) at io/qfileinfo.cpp:154
#5  0x07a65bec in QFileInfo::isFile (this=0xb0951288) at io/qfileinfo.cpp:969
#6  0x07a5d37b in QDirIteratorPrivate::matchesFilters (this=0xa98e69e8, fileName=..., fi=...) at io/qdiriterator.cpp:319
#7  0x07a5db7d in QDirIteratorPrivate::advance (this=0xa98e69e8) at io/qdiriterator.cpp:222
#8  0x07a5e699 in QDirIteratorPrivate (this=0xa98e69e8, path=..., nameFilters=..., filters=..., flags=...) at io/qdiriterator.cpp:170
#9  0x07a5e87a in QDirIterator (this=0xb095139c, path=..., nameFilters=..., filters=..., flags=...) at io/qdiriterator.cpp:435
#10 0x07a590ea in QDir::entryInfoList (this=0xb09515b8, nameFilters=..., filters=..., sort=...) at io/qdir.cpp:1409
#11 0x07a5931f in QDir::entryInfoList (this=0xb09515b8, filters=..., sort=...) at io/qdir.cpp:1326
#12 0x0815f3e0 in UPnpMedia::buildFileList (this=0x8739bc8, directory=..., rootID=0, itemID=133019, query=...) at upnpmedia.cpp:132
#13 0x0815fd31 in UPnpMedia::buildFileList (this=0x8739bc8, directory=..., rootID=0, itemID=133019, query=...) at upnpmedia.cpp:171
#14 0x0815fd31 in UPnpMedia::buildFileList (this=0x8739bc8, directory=..., rootID=0, itemID=133018, query=...) at upnpmedia.cpp:171
#15 0x0815fd31 in UPnpMedia::buildFileList (this=0x8739bc8, directory=..., rootID=0, itemID=133017, query=...) at upnpmedia.cpp:171

[the last frame repeats with differing itemID arguments...]

#24262 0x0815fd31 in UPnpMedia::buildFileList (this=0x8739bc8, directory=..., rootID=0, itemID=108770, query=...) at upnpmedia.cpp:171
#24263 0x0815fd31 in UPnpMedia::buildFileList (this=0x8739bc8, directory=..., rootID=100000, itemID=105438, query=...) at upnpmedia.cpp:171
#24264 0x081615a3 in UPnpMedia::BuildMediaMap (this=0x8739bc8) at upnpmedia.cpp:272
#24265 0x0815ee71 in UPnpMedia::RunRebuildLoop (this=0x8739bc8) at upnpmedia.cpp:57
#24266 0x0815eeab in UPnpMedia::doUPnpMediaThread (param=0x8739bc8) at upnpmedia.cpp:66
#24267 0x0025596e in start_thread (arg=0xb134fb70) at pthread_create.c:300
#24268 0x05ceda4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

So, I'd guess that the segfault is caused by mythbackend running out of stack, as it is having trouble dealing with the metadata or directory name.

I'm running mythbackend with the 0.23.1 'autobuild' packages for Ubuntu 10.04:

[jk@backend ~]$ mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version   : 26057
MythTV Branch    : branches/release-0-23-fixes
Network Protocol : 23056
Library API      : 0.23.1.201000710-1
QT Version       : 4.6.2
Options compiled in:
 linux debug using_oss using_alsa using_pulse using_jack using_pulseoutput using_backend using_dvb using_firewire using_frontend using_glx_proc_addr_arb using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libudev using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

[Jeremy Kerr <jk@…>]

gdb backtrace of all threads, gzipped

[Jeremy Kerr <jk@…>]

If I set LC_ALL=en_AU.UTF-8, the problem no longer occurs.

[beirdo]

Although the workaround was found, I think it is important to keep it from going into recursive loops in these very specific circumstances anyways. Bad data should not cause segfaults, ideally.

This section of code is likely to be removed after 0.24, but let's not let this kill us in the meantime.

[beirdo]

I have attached a patch that I think should prevent this from reoccurring. I have yet to test it beyond compilability, but I thought I'd share it.

[beirdo]

Fixed by [26161]. Forgot to add it to the commit message.