Opened 11 years ago
Closed 11 years ago
#11241 closed Bug Report - Crash (Fixed)
Mythfrontend crashes on exiting video in Video Library
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | blocker | Milestone: | 0.27 |
Component: | MythTV - Video Decoding | Version: | 0.26-fixes |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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.
Attachments (1)
Change History (11)
comment:1 Changed 11 years ago by
Status: | new → infoneeded_new |
---|---|
Summary: | Mythfrontend crashes on exiting video in Mythvideo plugin → Mythfrontend crashes on exiting video in Video Library |
comment:2 Changed 11 years ago by
I also have a relatively small (~30Mb) example video that reproducably crashes the Video Library. Any way to get that to you easily?
comment:3 Changed 11 years ago by
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.
comment:4 Changed 11 years ago by
No need to exchange video's. I just discovered that "Big Buck Bunny" SD test in Setup Wizard crashes as well when exiting.
comment:5 Changed 11 years ago by
Component: | MythTV - Video Playback → MythTV - Video Decoding |
---|---|
Status: | infoneeded_new → new |
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.
comment:6 follow-up: 7 Changed 11 years ago by
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...
comment:7 Changed 11 years ago by
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.
comment:8 Changed 11 years ago by
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.
comment:9 Changed 11 years ago by
Milestone: | unknown → 0.27 |
---|---|
Priority: | minor → blocker |
Status: | new → infoneeded_new |
Can you update to 0.27-RC1 and try again. I suspect this is now fixed following [6e62a3c6].
comment:10 Changed 11 years ago by
Resolution: | → Fixed |
---|---|
Status: | infoneeded_new → closed |
Reported fixed in IRC
Could you produce a traceback from the core dump created during the segmentation fault?