Opened 8 years ago

Closed 6 years ago

#10075 closed Bug Report - Crash (Unverified)

Frontend abort on DVB playback start with Xv

Reported by: otto@… Owned by:
Priority: major Milestone: 0.27
Component: MythTV - Video Playback Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Attached backtrace show frontend abort/crash when DVB recording playback is started. This has only happened once or twice, and is not really reproducible. Backtrace shows execution within: VideoOutputXv::CreateShmImages?()

Git version is: c51b922b7b8f76ebf761d25580465c4666228cc2

Attachments (7)

playback-start-bt.txt (70.2 KB) - added by anonymous 8 years ago.
mfe-version.txt (651 bytes) - added by anonymous 8 years ago.
mfe-playback-abort-log1.txt (4.6 KB) - added by otto@… 8 years ago.
playback-start-bt2.txt (58.6 KB) - added by otto@… 8 years ago.
mfe-playback-abort-log2.txt (4.6 KB) - added by otto@… 8 years ago.
playback-start-bt3.txt (50.6 KB) - added by otto@… 8 years ago.
mfe-playback-abort-log3.txt (51.5 KB) - added by otto@… 8 years ago.

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by anonymous

Attachment: playback-start-bt.txt added

Changed 8 years ago by anonymous

Attachment: mfe-version.txt added

comment:1 Changed 8 years ago by markk

Otto - do you have the associated mythfrontend logs referenced in the bt? Might help shed some light on the root cause.

While the decoder thread (running CreateShmImages?) initially looks at fault (and the stack for that thread is similar to an X thread related crash), it looks as if it is actually the main thread that is aborting - std::terminate - but there is absolutely no hint as to why.

Changed 8 years ago by otto@…

Attachment: mfe-playback-abort-log1.txt added

Changed 8 years ago by otto@…

Attachment: playback-start-bt2.txt added

Changed 8 years ago by otto@…

Attachment: mfe-playback-abort-log2.txt added

comment:2 in reply to:  1 Changed 8 years ago by otto@…

Otto - do you have the associated mythfrontend logs referenced in the bt? Might help shed some light on the root cause.

While the decoder thread (running CreateShmImages?) initially looks at fault (and the stack for that thread is similar to an X thread related crash), it looks as if it is actually the main thread that is aborting - std::terminate - but there is absolutely no hint as to why.

I've attached log related to the original abort. I've also attached second backtrace and associated log from another abort.

Couple of things to notice:

  • this is happening with a channel that has had problems with Myth over the years (YLE1 in Finland)
  • log shows audio with 0 channels (see old issues: #8596, #3731)
  • this file is played with Playback Group that has 1.3x time-stretch

comment:3 Changed 8 years ago by markk

Can you post the full output of mythfrontend -v playback --loglevel=debug for a crash - and confirm what GPU and driver you are using?

A couple of things to test:-

  • what happens if time stretch is disabled? (i.e. is at 1x)
  • what happens if you comment out the disp->Sync() line in VideoOutputXv::CreateShmImages??

thanks, Mark

(p.s. looks like it is a crash in X, though that section of code is pretty heavily locked so I can't honestly see where the problem is)

Changed 8 years ago by otto@…

Attachment: playback-start-bt3.txt added

Changed 8 years ago by otto@…

Attachment: mfe-playback-abort-log3.txt added

comment:4 in reply to:  3 ; Changed 8 years ago by otto@…

Replying to markk:

Can you post the full output of mythfrontend -v playback --loglevel=debug for a crash - and confirm what GPU and driver you are using?

Attached new backtrace and corresponding log with debug log level. GPU is nVidia GeForce? 6200 and driver is nVidia's 260.19.36 (Fedora 13).

A couple of things to test:-

  • what happens if time stretch is disabled? (i.e. is at 1x)
  • what happens if you comment out the disp->Sync() line in VideoOutputXv::CreateShmImages??

With 1.3x time stretch, the problem occurs 4 times out of 5 with one particular file. When time stretch is disabled, problem goes away (tested 10 times).

Haven't yet tested the code change, I'll get back to that later.

comment:5 in reply to:  4 Changed 8 years ago by otto@…

A couple of things to test:-

  • what happens if you comment out the disp->Sync() line in VideoOutputXv::CreateShmImages??

Commenting that line sort of helps. Out of 10 playback startups only 2 now aborts, so it's not really fixed with that..

comment:6 Changed 7 years ago by markk

Milestone: unknown0.25
Status: newaccepted

comment:7 Changed 7 years ago by markk

Owner: markk deleted
Status: acceptedassigned

comment:8 Changed 7 years ago by beirdo

Milestone: 0.25unknown
Status: assignednew

comment:9 Changed 6 years ago by stuartm

Milestone: unknown0.27
Priority: minormajor
Status: newinfoneeded_new

Otto, can you still reproduce this issue?

There's not a great deal of interest in the community for maintaining the Xv code with the next-generation video renders - OpenGL and VDPAU (and vaapi) - being available. So I can't make any promises that this will be fixed if it's still an issue.

I'm setting a milestone of 0.27 because we are either able to fix it for that release, or we decide now it's never going to be fixed.

comment:10 in reply to:  9 Changed 6 years ago by otto@…

Replying to stuartm:

Otto, can you still reproduce this issue?

Haven't seen this for awhile after upgrading the distro (Fedora 15 -> 18). This should be closed as unverified/invalid.

comment:11 Changed 6 years ago by Nicolas Riendeau

Resolution: Unverified
Status: infoneeded_newclosed

Closed at submitter's request

Note: See TracTickets for help on using tickets.