Mythfrontend crashes on exiting video in Video Library

[Martin van Es <martin@…>]

I just upgraded to MythTV 0.26 using mythbuntu packages and am running version v0.26.0-35-g81e8fa5.

Since the upgrade mythfronted crashes on exiting (stop playing by pressing escape) a video played in mythvideo, leaving this trail in mythfrontend.log:

Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext tv_play.cpp:2155 (HandleStateChange) TV: Attempting to change from WatchingVideo to None
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: W CoreContext mythpainter.cpp:34 (Teardown) MythPainter: 2 images not yet de-allocated.
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext mythpainter_ogl.cpp:62 (ClearCache) Clearing OpenGL painter cache.
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext mythrender_opengl1.cpp:280 (DeleteOpenGLResources) OpenGL1: Deleting OpenGL Resources
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext mythrender_opengl.cpp:1042 (DeleteOpenGLResources) OpenGL: Deleting OpenGL Resources
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext tv_play.cpp:2394 (HandleStateChange) TV: Changing from WatchingVideo to None
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext tv_play.cpp:405 (StartTV) TV: Exiting main playback loop.
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: I CoreContext screensaver-x11.cpp:161 (RestoreDPMS) ScreenSaverX11Private: DPMS Reactivated 1
Nov 16 15:50:16 pandora mythlogserver: mythfrontend[2823]: C CoreContext signalhandling.cpp:305 (handleSignal) Received Segmentation fault: Code 1, PID -1505238032, UID -1702660735, Value 0xbabab4ada2938274

This only seems to happen with H.264 video, but not all H.264 videos have this problem.

[Raymond Wagner]

Could you produce a traceback from the core dump created during the segmentation fault?

[Martin van Es <martin@…>]

The backtrace that was asked for.

[Martin van Es <martin@…>]

I also have a relatively small (~30Mb) example video that reproducably crashes the Video Library. Any way to get that to you easily?

[Martin van Es <martin@…>]

There's another Video Library bug connected to this regression: all videos that make the Library crash have trouble keeping track of time after skipping. I.e. after a skip, current time = total time (but video continues where it was) and skipping is not possible anymore (it only forwards/rewinds by a couple of frames). The video mentioned above exposes both problems.

[Martin van Es <martin@…>]

No need to exchange video's. I just discovered that "Big Buck Bunny" SD test in Setup Wizard crashes as well when exiting.

[Raymond Wagner]

Here's the relevant bits from the backtrace.

Thread 1 (Thread 0x91e0db40 (LWP 3557)):
#0  put_pixels16_sse2 (h=16, line_size=720, pixels=0x9095b4f0 <Address 0x9095b4f0 out of bounds>, block=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>) at libavcodec/x86/dsputil_mmx.c:464
#1  put_h264_qpel16_mc00_sse2 (dst=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>, src=0x9095b4f0 <Address 0x9095b4f0 out of bounds>, stride=720) at libavcodec/x86/h264_qpel_mmx.c:1041
#2  0xb452f56e in mc_dir_part (chroma_idc=1, pixel_shift=0, chroma_op=0xb4870d10 <ff_put_h264_chroma_mc8_ssse3_rnd>, qpix_op=0xb952fdc, src_y_offset=120, src_x_offset=232, dest_cr=0x90d4a2c8 <Address 0x90d4a2c8 out of bounds>, dest_cb=0x90d30dc8 <Address 0x90d30dc8 out of bounds>, dest_y=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>, list=0, delta=0, height=16, square=1, n=0, pic=0xb97e734, h=0xb94f600) at libavcodec/h264.c:500
#3  mc_part_std (y_offset=120, x_offset=232, chroma_idc=1, pixel_shift=0, list1=16384, list0=<optimized out>, chroma_avg=0xb48711c0 <ff_avg_h264_chroma_mc8_ssse3_rnd>, qpix_avg=0xb9530dc, chroma_put=0xb4870d10 <ff_put_h264_chroma_mc8_ssse3_rnd>, qpix_put=0xb952fdc, delta=0, height=16, square=1, n=0, h=0xb94f600, dest_cr=0x90d4a2c8 <Address 0x90d4a2c8 out of bounds>, dest_cb=0x90d30dc8 <Address 0x90d30dc8 out of bounds>, dest_y=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>) at libavcodec/h264.c:602
#4  mc_part (chroma_put=0xb4870d10 <ff_put_h264_chroma_mc8_ssse3_rnd>, chroma_idc=1, pixel_shift=0, list1=16384, list0=<optimized out>, weight_avg=0xb9548ec, weight_op=0xb9548dc, chroma_avg=0xb48711c0 <ff_avg_h264_chroma_mc8_ssse3_rnd>, qpix_avg=0xb9530dc, qpix_put=0xb952fdc, y_offset=0, x_offset=0, dest_cr=0x90d4a2c8 <Address 0x90d4a2c8 out of bounds>, dest_cb=0x90d30dc8 <Address 0x90d30dc8 out of bounds>, dest_y=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>, delta=0, square=1, n=0, h=0xb94f600, height=16) at libavcodec/h264.c:748
#5  hl_motion (chroma_idc=1, pixel_shift=0, weight_avg=0xb9548ec, weight_op=0xb9548dc, chroma_avg=0xb952fd0, qpix_avg=0xb9530dc, chroma_put=0xb952fc4, qpix_put=0xb952fdc, dest_cr=0x90d4a2c8 <Address 0x90d4a2c8 out of bounds>, dest_cb=0x90d30dc8 <Address 0x90d30dc8 out of bounds>, dest_y=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>, h=0xb94f600) at libavcodec/h264.c:799
#6  hl_motion_420 (weight_avg=0xb9548ec, weight_op=0xb9548dc, chroma_avg=0xb952fd0, qpix_avg=0xb9530dc, qpix_put=0xb952fdc, pixel_shift=0, chroma_put=0xb952fc4, dest_cr=0x90d4a2c8 <Address 0x90d4a2c8 out of bounds>, dest_cb=0x90d30dc8 <Address 0x90d30dc8 out of bounds>, dest_y=0x90ceb4f0 <Address 0x90ceb4f0 out of bounds>, h=0xb94f600) at libavcodec/h264.c:900
#7  hl_decode_mb_internal (pixel_shift=0, simple=1, h=0xb94f600) at libavcodec/h264.c:2211
#8  hl_decode_mb_simple_8 (h=0xb94f600) at libavcodec/h264.c:2413
#9  ff_h264_hl_decode_mb (h=0xb94f600) at libavcodec/h264.c:2451
#10 ff_h264_hl_decode_mb (h=0xb94f600) at libavcodec/h264.c:2434
#11 0xb4570ac1 in decode_slice (avctx=0xb6edfa0, arg=0x91e0d16c) at libavcodec/h264.c:4013
#12 0xb45710d5 in execute_decode_slices (h=0xb94f600, context_count=1) at libavcodec/h264.c:4162
#13 0xb45758e7 in decode_nal_units (h=0xb94f600, buf=0x8de00040 "", buf_size=170) at libavcodec/h264.c:4457
#14 0xb45764b2 in decode_frame (avctx=0xb6edfa0, data=0xb8046b0, data_size=0xb805020, avpkt=0xb804668) at libavcodec/h264.c:4569
#15 0xb46ff6d8 in frame_worker_thread (arg=0xb804598) at libavcodec/pthread.c:381
#16 0xb6398d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#17 0xb5257d3e in clone () from /lib/i386-linux-gnu/libc.so.6

It seems possible this could be an upstream issue.

[martin@…]

I guess this won't be addressed until 0.27 then. Any chances 0.27 will come with new libavcodec libs?

Really surprised I'm the only experiencing this (on two machines!) though...

[josh@…]

Replying to martin@…:

Really surprised I'm the only experiencing this (on two machines!) though...

I've been following this bug for a few months. Definitely a +1 as I'm experiencing this also with a reasonably large number of files.

[martin@…]

Good to hear I'm not the only one.

This weekend I tried to use 0.27's libmythav* libs in 0.26-fixes in several combinations. ldd -r showed no problems, but I had no working video so reverted the test.

[stuartm]

Can you update to 0.27-RC1 and try again. I suspect this is now fixed following [6e62a3c6].

[stuartm]

Reported fixed in IRC