Steps to reproduce: 1) Ensure patch for bug 791164 and bug 759506 is applied. 2) copy an h.264 video into /sdcard/Movies (eg. http://cd.pn/b2/story.mp4) 3) Start video app What happens: 4) Video app crashes What should happen: 4) List of videos should appear. The crash occurs during thumbnail generation. If I comment out that part of the video app things work fine. Stack trace: E/omx_vdec( 416): Warning - previous ts > current ts. And both are non B-frames F/OMXCodec( 416): frameworks/base/media/libstagefright/OMXCodec.cpp:3804 CHECK(info->mStatus == OWNED_BY_US || info->mStatus == OWNED_BY_NATIVE_WINDOW) failed. F/libc ( 416): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) I/DEBUG ( 109): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 109): Build fingerprint: 'toro/full_otoro/otoro:4.0.4.0.4.0.4/OPENMASTER/eng.chris.20120822.165132:eng/test-keys' I/DEBUG ( 109): pid: 416, tid: 433 >>> /system/b2g/plugin-container <<< I/DEBUG ( 109): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad I/DEBUG ( 109): r0 deadbaad r1 00000001 r2 40000000 r3 00000000 I/DEBUG ( 109): r4 00000000 r5 00000027 r6 00000000 r7 00000001 I/DEBUG ( 109): r8 00000000 r9 426e2488 10 00100000 fp 00000001 I/DEBUG ( 109): ip 400ad12c sp 44d547d0 lr 4004c819 pc 40048ba8 cpsr 60000030 I/DEBUG ( 109): d0 64656c6961662029 d1 6964656d2f657361 I/DEBUG ( 109): d2 61747362696c2f61 d3 7468676972666567 I/DEBUG ( 109): d4 65646f43584d4f2f d5 38333a7070632e63 I/DEBUG ( 109): d6 4b43454843203430 d7 6d3e2d6f666e6928 I/DEBUG ( 109): d8 0000000000000000 d9 0000000000000000 I/DEBUG ( 109): d10 0000000000000000 d11 0000000000000000 I/DEBUG ( 109): d12 0000000000000000 d13 0000000000000000 I/DEBUG ( 109): d14 0000000000000000 d15 0000000000000000 I/DEBUG ( 109): d16 3d20737574617453 d17 5f44454e574f203d I/DEBUG ( 109): d18 7c7c2053555f5942 d19 6d3e2d6f666e6920 I/DEBUG ( 109): d20 3d20737574617453 d21 5f44454e574f203d I/DEBUG ( 109): d22 564954414e5f5942 d23 574f444e49575f45 I/DEBUG ( 109): d24 1188d9f5f2d70000 d25 bfa47a5a2db6ff72 I/DEBUG ( 109): d26 0000000000000000 d27 0000000000000000 I/DEBUG ( 109): d28 f79ed6ba00000000 d29 10828c51dedbf7be I/DEBUG ( 109): d30 0000000000000000 d31 0000000000000000 I/DEBUG ( 109): scr 20000011 I/DEBUG ( 109): I/DEBUG ( 109): #00 pc 00017ba8 /system/lib/libc.so I/DEBUG ( 109): #01 pc 0000144a /system/lib/liblog.so (__android_log_assert) I/DEBUG ( 109): #02 pc 00078650 /system/lib/libstagefright.so (_ZN7android8OMXCodec17freeBuffersOnPortEmb) I/DEBUG ( 109): #03 pc 00079044 /system/lib/libstagefright.so (_ZN7android8OMXCodec13onStateChangeE13OMX_STATETYPE) I/DEBUG ( 109): #04 pc 00079bde /system/lib/libstagefright.so (_ZN7android8OMXCodec13onCmdCompleteE15OMX_COMMANDTYPEm) I/DEBUG ( 109): #05 pc 0007ad68 /system/lib/libstagefright.so (_ZN7android8OMXCodec7onEventE13OMX_EVENTTYPEmm) I/DEBUG ( 109): #06 pc 0007b014 /system/lib/libstagefright.so (_ZN7android8OMXCodec10on_messageERKNS_11omx_messageE) I/DEBUG ( 109):

This patch is to disable thumbnail generation to allow h.264 videos to play with bug 759506 applied. It is not an attempt at a fix.

The crash occurs in the OmxDecoder destructor while calling mVideoSource->stop(). Adding some debugging I notice the destructor is called on a different thread than when it was constructed which is probably bad.

The crash is caused by the OmxDecoder being created on one thread and destroyed on another. Patch coming shortly.

Once I looked at the thread issue, the crash was occurring during normal video playback, when playback was completed. The crash is caused by an assertion with the mVideoSource->stop is called and there are internal video buffers still live. Some debugging shows that one buffer is still active when the OmxDecoder object is destroyed and that's the one currently stored in the image container to display the current frame. Clearing out this frame on destruction of the OmxDecoder object resolves the crash. Thumbnails display and normal playback completes without crashing.

Did you mean to re-request triage on this bug? I'm assuming that was an accident, so resetting to blocking.

Thanks, it was an accident. I noticed it changed but don't have the permissions to change it to + myself.

Clear out the image in the image container which holds onto the last video buffer preventing the stagefright video source to shut down cleanly. The patch requires bug 759506 for the small content/media/omx change.

Comment on attachment 663202 [details] [diff] [review] Fix Review of attachment 663202 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/media/VideoFrameContainer.cpp @@ +63,5 @@ > +void VideoFrameContainer::ClearCurrentFrame() > +{ > + MutexAutoLock lock(mMutex); > + > + nsRefPtr<Image> kungFuDeathGrip; Comment explaining why we need this please. This looks like the same solution to the same problem Edwin showed me the other day...

(In reply to Chris Pearce (:cpearce) from comment #8) > This looks like the same solution to the same problem Edwin showed me the > other day... Not quite. Edwin's fix is to hang on to the Image in the SetCurrentFrame call while changing it and solves a deadlock issue. This fix adds ClearCurrentFrame to basically SetCurrentFrame a null image, releasing held video buffers. The kungFuDeathGrip is added from copying Edwin's code to hold onto the image until the end of the call and I'll add a comment to this effect when landing.

Address review comment by adding comment to kungFuDeathGrip. Carry r+ forward.

https://hg.mozilla.org/integration/mozilla-inbound/rev/6f7a7e009aa9 https://hg.mozilla.org/integration/mozilla-inbound/rev/3876b8007889 https://hg.mozilla.org/integration/mozilla-inbound/rev/69d3a8308851 https://hg.mozilla.org/integration/mozilla-inbound/rev/18becb73b906