Mythfrontend crashes with segfault

[anonymous]

When I start mythfrontend from my fluxbox script, it crashes with a SEGFAULT.

When I start mythfrontend from the terminal in fluxbox itself (on the commandline), it works fine.

I will attach backtrace and frontend log.

[anonymous]

GDB backtrace of mythfrontend

[anonymous]

Log of the frontend, trimmed because of the size limitations

[anonymous]

I just found out it only works when I start mythfrontend from the command-line with -v all

If I do not specify this verbosity level, it does not work.

[anonymous]

I am using trunk version 23022, compiled by GCC-4.3.3 on a VIA Epia 1Ghz processor, distcc and compiler cache are not used.

My Configure settings:

# Basic Settings
Compile type              debug
Compiler cache            no
DistCC                    no
qmake                     /usr/bin/qmake
install prefix            /usr/local
runtime prefix            /usr/local
CPU                       x86 x86_32 (c3-2)
big-endian                no
runtime cpu detection     no
yasm                      yes
MMX enabled               yes
MMX2 enabled              no
3DNow! enabled            no
3DNow! extended enabled   no
SSE enabled               yes
SSSE3 enabled             no
CMOV enabled              yes

# Input Support
Joystick menu             no
lirc support              yes
Video4Linux sup.          yes
ivtv support              no
HD-PVR support            no
FireWire support          no
DVB support               no [/usr/include]
DVB-S2 support            no
HDHomeRun support         no
IPTV support              no

# Sound Output Support
PulseAudio support        no
OSS support               no
ALSA support              yes
JACK support              no
libfftw3 support          no

# Video Output Support
x11 support               yes
xrandr support            no
xv support                yes
XvMC support              yes
XvMC VLD support          yes
XvMC pro support          no
XvMC libs                 -lchromeXvMC
VDPAU support             no
OpenGL video              no
OpenGL vsync              no
DirectFB                  no
Fribidi formatting        yes
MHEG support              no

# Misc Features
multi threaded libavcodec yes
Frontend                  yes
Backend                   yes

# Bindings
bindings_perl             yes
bindings_python           yes

Creating libs/libmythdb/mythconfig.h and libs/libmythdb/mythconfig.mak

WARNING: When using --arch=X or --cpu=X you must include the
         output of ./configure along with any bug report.


Configuration settings:

        qmake          /usr/bin/qmake

        MythArchive    plugin will not be built
        MythBrowser    plugin will be built
        MythGallery    plugin will be built
        MythGame       plugin will not be built
        MythMusic      plugin will be built
        MythNews       plugin will be built
        MythVideo      plugin will be built
        MythWeather    plugin will be built
        MythZoneMinder plugin will not be built
        MythMovies     plugin will not be built
        OpenGL         support will be included in MythGallery
        EXIF           support will be included in MythGallery
        OpenGL         support will be included in MythMusic
        libvisual      support will be included in MythMusic
        FFTW v.3       support will be included in MythMusic
        SDL            support will be included in MythMusic

mythfrontend --version

Please include all output in bug reports.
MythTV Version   : 23020
MythTV Branch    : trunk
Network Protocol : 55
Library API      : 0.23.20091228-1
QT Version       : 4.6.0
Options compiled in:
 linux release using_alsa using_backend using_fribidi using_frontend using_lirc using_qtwebkit using_v4l using_x11 using_xv using_xvmc using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads

[Mike Nix <mnix@…>]

I can confirm this on one of my 3 myth boxes.

I have: 1 master/frontend - this works just fine 1 slave/frontend - this crashes in mythfrontend the same as above (when calling readyRead)

both of the above are identical boxes as far as other software (they are dedicated myth boxes)

My third box is my own machine / development box - which works fine.

I originally noticed the problem with gcc-4.2. If I run under gdb it is still there, but if I run mythfrontend under valgrind it doesn't crash.

I did upgrade to gcc-4.3.3 and now the boxes that work are fine, and the one that crashed now crashes with "illegal instruction" for both back and front ends.

I suspect the problem is somewhere other than the locations in the logs :(

[Mike Nix <mnix@…>]

I re-built everything (kernel, dvb modules. mythtv) with gcc-4.3.3 and still get the segfault. I built Mythtv with --compile-type=debug and "gdb mythfrontend -v all" ends with the following:

2009-12-30 18:30:08.488 MythSocketThread(sock 0x8addb78:34): socket is
readable
2009-12-30 18:30:08.488 MythSocketThread(sock 0x8addb78:34): calling
m_cb->readyRead()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xaf6cdb90 (LWP 23359)]
0xb61f3e40 in MythSocket::state (this=0x0) at mythsocket.cpp:114
114         return m_state;

I will look at a backtrace and determine why the MythSocket object is NULL tomorrow.

[sphery]

Please attach the full thread backtrace as described at http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2 .

[brtab]

I have run into this same problem running:

mythfrontend --version

Please include all output in bug reports. MythTV Version : 23029 MythTV Branch : trunk Network Protocol : 56 Library API : 0.23.20091229-1 QT Version : 4.5.3 Options compiled in:

linux debug using_oss using_alsa using_pulse using_pulseoutput using_backend using_dvb using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv 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_live using_mheg

Mythfrontend will sometimes (about 10% of the time) start and work normally. Backtrace attached.

[Mike Nix <mnix@…>]

temporary patch

[Mike Nix <mnix@…>]

The bug shows up when mythsocketthread finds a socket in m_readyread_list that is ready to read when MythContext::d->eventSock is NULL.

readyRead assumes d->eventSock is the socket to read.

I can see three possible solutions: 1: if (!d->eventSock) return; ie ignore the socket - probably bad 2: have readyRead use the socket passed to it. 3: make some code behave differently for sock != d->eventSock

I don't know if m_readyread_list is intended to hold non-event sockets so I can't answer the question. The attached patch uses the socket passed to readyRead, and adds code to log what is happening for further diagnostics.

[danielk]

(In [23059]) Fixes #7819. Use the passed in socket for readyRead, it will always be the correct socket.

[danielk]

(In [23060]) Refs #7819. Add serverSock and eventSock locking in 3 methods that didn't have it. Use QMutexLocker to in the methods where we were already doing proper locking to avoid any future forgetten unlock problems. Rename the lock from serverSockLock to sockLock and add a few comments so future maintainers know what to do.