mythfrontend segfaults sitting at watch recordings screen

[Ken Emerson <kenneth.emerson@…>]

Approximately 1 minute after selecting watch recordings, frontend segfaults. Using Blue Abstract theme. Could this be a theme problem?

ken@mythtv:~$ mythfrontend --version Please include all output in bug reports. MythTV Version : 23050 MythTV Branch : trunk Network Protocol : 56 Library API : 0.23.20091229-1 QT Version : 4.5.0 Options compiled in:

linux debug using_oss using_alsa using_backend using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync 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

Backtrace attached.

[Ken Emerson <kenneth.emerson@…>]

Backtrace from corefile

[sphery]

Looks like playbackbox.cpp (around line 1195) is calling MythUIButtonList::GetItemAt?() and passing an arg of -1, which results in calling QList::at() with an arg of -1, which triggers a Qt abort due to a failed assert. Robert McNamara? has a little patch that checks the bounds in GetItemAt?(), but since the code generally doesn't check validity of the value returned by GetItemAt?(), we'd need to modify every location where GetItemAt?() is called. And, even then, we probably still need to fix the issue of calling GetItemAt?() with an invalid value. I'll leave it to the MythUI experts to decide what the best approach is--just thought I'd mention this in case it saves someone else 30 seconds of digging. :)

[danielk]

This was already fixed last week, please svn up