[mythtv-users] SEGV in mythfrontend (CVS version) when changing
isely at isely.net
Mon Dec 20 06:13:23 UTC 2004
I've been chasing a problem where mythfrontend dies with a SEGV when a
channel change takes place. I've gotten pretty far into this and I'm
fairly convinced that it's a race condition that starts with the decoder
thread and eventually wipes out the thread running the video loop. Here's
a (rough) sequence. Note that line numbers are approximate due to my
insertions of traceprint in order to understand the problem:
1. TV::ChangeChannelByString() gets called, performing a number of
2. Some time after activenvp->Pause() (roughly line 2704) but possibly
before the call to activerecorder->Pause() (roughtly line 2714),
m_parent->SetEof() gets called from within NuppelDecoder::GetFrame().
This is at roughly line 997 of nuppeldecoder.cpp. I *think* this is a
different thread context than step 1 above. That sets in motion a chain
of events that follows roughly like this:
3. The member variable "eof" gets set in NuppelVideoPlayer.
4. The main loop in NuppelVideoPlayer::StartPlaying() aborts due to eof
5. On the way out, NuppelVideoPlayer::StartPlaying() sets the member
variable killvideo to true (and then blocks on a pthread_join(), waiting
for the obvious)...
6. The thread running NuppelVideoPlayer::OutputVideoLoop() aborts its main
loop, due to killvideo being nonzero.
7. On the way out of NuppelVideoPlayer::OutputVideoLoop(), the videoOutput
variable is deleted, and the pointer nulled.
8. A little further along in TV::ChangeChannelByString() (back to original
thread now) a call is made to activenvp->ResetPlaying(). This then calls
NuppelVideoPlayer::clearAfterSeek() which in turn dereferences the null
videoOutput pointer to call its clearAfterSeek() function...
I noted that NuppelVideoPlayer::clearAfterSeek() is not checking
videoOutput to be safe (like it is in most other places), so I added a
check. However that just changes the SEGV into a hang, probably because I
imagine that getting that eof early on may have been the wrong thing to
happen and so with no video stream coming in things get messed up in a
hurry. The exact line which called SetEof() is a reaction to what appears
to be a short read in the decoder video stream (failed to read enough
bytes to match the packet length in the header). Could the channel change
somehow have randomly interrupted the video stream in such a way as to
confuse the decoder and cause it to seize up?
The problem is very intermittent, and it looks to involve a race among at
least 2 maybe more threads. I'm not completely certain of all the details
yet and I at this moment have no idea how to actually solve this, though I
suspect the code which called SetEof() is probably the root cause. I've
only been studying this source code for maybe a couple days and am still
learning my way around.
I guess before I dig any deeper I should ask if this is a known problem
with a known solution that just isn't in CVS yet... The CVS snapshot I
used I believe was up to date as of Friday (17-Dec). Should I keep
chasing? Can someone suggest some avenues for further digging and save me
time learning this source code? I haven't yet found the exact
relationship between steps 1 & 2 above.
For this bug, the hardware setup is an Athlon 3200+ system with a
Hauppauge WinTV-Go tuner card (operated by mythtv as a stock V4L device).
Kernel version is 2.6.9-ac14 with current 2.6.9 "new tuners" patch and the
latest V4L patch (2.6.9-rc4 I think?). Generally it will happen on the
very first attempt to change the channel while watching live TV. If it
doesn't happen the first time, it seems not to happen at all - so restart
mythfrontend to take another whack at it. It seems to happen for me about
1/5 of the time.
BTW, what led me to trying CVS was problems I was having with mythtv 0.16
involving the transcoder failing (transcode from mpeg2 from a PVR-250 to
mpeg4). The current CVS of mythtv appears not to have this problem, but
now I instead see this issue when trying to change channels using a
I'm more than willing to chase this issue on my own, as I've been doing.
But I'd like to be sure I'm not duplicating effort already undertaken.
So, do I continue?
| Mike Isely | PGP fingerprint
POSITIVELY NO | | 03 54 43 4D 75 E5 CC 92
UNSOLICITED JUNK MAIL! | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
More information about the mythtv-users