mythfrontend crashes after a little while when using VDPAU

[Jake Goulding <shepmaster@…>]

I know this is with VDPAU, but I might as well report it anyway.

Using vdpau (as setup from ​http://mythtv.org/wiki/index.php/VDPAU), mythfrontend will segfault after about 15-30 minutes of watching Live TV. The backtrace is attached.

nvidia-drivers version 180.22

/usr/local/bin/mythfrontend --version
Please include all output in bug reports.
MythTV Version   : 19634
MythTV Branch    : trunk
Library API      : 0.22.20090108-1
Network Protocol : 43
QT Version       : 4.3.3
Options compiled in:
 linux debug using_alsa using_jack using_backend using_dvb using_frontend using_hdpvr using_iptv using_ivtv using_libfftw3 using_lirc using_mheg using_opengl_video 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

[Jake Goulding <shepmaster@…>]

Backtrace (thread apply all bt full)

[paulh]

Is that the full BT it seems to be missing the important part telling us where the segfault was?

[Jake Goulding <shepmaster@…>]

Sure enough - I thought I had the right settings set for vdpau to have symbols. I tried again, and setting the magic vdpau environment variables:

export VDPAU_TRACE=1
export VDPAU_NVIDIA_DEBUG=3

Seems to cause Myth vdpau init to fail. I have a ​question out at the NVidia forums to see what I am doing wrong.

[Jake Goulding <shepmaster@…>]

According to the NVidia forums, Myth failing to initialize when TRACE=1 is Myth's fault.. He says that the trace shows that everything is being setup correctly. Could you try setting TRACE=1 and see if it also causes your frontend to fail vdpau init?

[anonymous]

Setting VDPAU_TRACE=1 causes Mythtv to crash in VDPAUContext::CheckCodecSupported?. Without setting it, playback is perfectly stable (for me at least). I fail to see how that is a Mythtv problem.

Jake - if you want to help track this down, as has already been noted, you need to try and grab a more informative backtrace (see the docs) that indicates where the seg fault is happening AND provide the associated frontend log (-v playback) that puts it in context (i.e. what the frontend was doing to trigger it).

If you want to add the VDPAU_TRACE information, try adding "return = true;" at around line 1484 of util-vdpau.cpp. That should give you playback of recordings - still fails further down the track on live tv though. The extra trace information may not be useful if it is a mythtv bug though.

(p.s. and make sure you're up to date with trunk.)

[anonymous]

Replying to anonymous:

Setting VDPAU_TRACE=1 causes Mythtv to crash in VDPAUContext::CheckCodecSupported?. Without setting it, playback is perfectly stable (for me at least). I fail to see how that is a Mythtv problem.

That's not the same that I see. When I set TRACE=1, vdpau fails to init inside of Myth, which then falls back to MPEG2VIDEO. The frontend definitely does not crash.

Jake - if you want to help track this down, as has already been noted, you need to try and grab a more informative backtrace (see the docs) that indicates where the seg fault is happening AND provide the associated frontend log (-v playback) that puts it in context (i.e. what the frontend was doing to trigger it).

I think I missed a step somewhere - I thought I had to set TRACE in order to get the symbols inside libvdpau? Obviously, you are getting those without doing that. What setting am I missing?

If you want to add the VDPAU_TRACE information, try adding "return = true;" at around line 1484 of util-vdpau.cpp. That should give you playback of recordings - still fails further down the track on live tv though. The extra trace information may not be useful if it is a mythtv bug though.

I'll add that once I figure out how to get the right symbols.

(p.s. and make sure you're up to date with trunk.)

Yep, I've been watching -commits and -dev for anything interesting, and updating every few days.

[Dibblah]

Should be fixed in current trunk, unless I'm mistaken - Probably caused by a mildly corrupted stream.