Opened 14 years ago
Closed 14 years ago
Last modified 14 years ago
#7819 closed defect (fixed)
Mythfrontend crashes with segfault
Reported by: | anonymous | Owned by: | Isaac Richards |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - General | Version: | unknown |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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.
Attachments (4)
Change History (13)
Changed 14 years ago by
Attachment: | backtrace.txt added |
---|
Changed 14 years ago by
Attachment: | mythfrontend.log added |
---|
Log of the frontend, trimmed because of the size limitations
comment:1 Changed 14 years ago by
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.
comment:2 Changed 14 years ago by
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
comment:3 Changed 14 years ago by
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 :(
comment:4 Changed 14 years ago by
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.
comment:5 Changed 14 years ago by
Please attach the full thread backtrace as described at http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2 .
comment:6 Changed 14 years ago by
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.
comment:7 Changed 14 years ago by
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.
comment:8 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 Changed 14 years ago by
(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.
GDB backtrace of mythfrontend