Crash in mozilla::H264Converter::Decode: MOZ_RELEASE_ASSERT(!mDecodePromiseRequest.Exists() && !mInitPromiseRequest.Exists())

RESOLVED FIXED in Firefox 55

Status

()

defect
P1
critical
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: kanru, Assigned: jya)

Tracking

({crash, regression})

52 Branch
mozilla55
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox53 unaffected, firefox54- wontfix, firefox55 fixed)

Details

(crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-af61d399-8882-4e1c-b721-ddba12170217.
=============================================================

It looks like it's only on FennecAndroid. The first crash appears in build 20170216110238. Bug 1336431 looks suspicious to me.
Flags: needinfo?(jyavenard)
Put this on John's plate. :-)
Flags: needinfo?(jyavenard) → needinfo?(jolin)
This is the top crash on Fennec Aurora in the last 7 days: https://crash-stats.mozilla.com/topcrashers/?product=FennecAndroid&version=54.0a2&days=7.

Can we get a follow up on Comment 1?  Thanks!
Oops! I think this can be fixed by bug 1345599, which I forgot to uplift to aurora. Sorry about that.
Depends on: 1345599
Flags: needinfo?(jolin)
Are you sure? the crash is due to an assert where somehow H264Converter::Decoder gets called prior the previous decode promise (or init promise) having completed.

That can only be a bug in H264Converter I think...
(In reply to Jean-Yves Avenard [:jya] from comment #4)
> Are you sure? the crash is due to an assert where somehow
> H264Converter::Decoder gets called prior the previous decode promise (or
> init promise) having completed.
> 
> That can only be a bug in H264Converter I think...

 Those 2 promise requests asserted are only tracked in DecodeFirstSample() and CreateDecoderAndInit(), respectively.
 It seems the crashes started to happen after bug 1336431, so it's likely that the modifications there causes this problem.
 Only DecodeFirstSample() is mentioned in one of the patches and that was reverted in bug 1345599, so I figured it can fix the crash.
Happening in 54 but not seen in 55.
Priority: -- → P1
this crash signature is starkly spiking up on desktop nightly after build 20170602030204 to crashes with over 100 installations per day.
those reports, like bp-964edd66-15a7-471d-87b6-2031c0170604, all have "MOZ_RELEASE_ASSERT(!mDecodePromiseRequest.Exists() && !mInitPromiseRequest.Exists()) (Can't request a new decode until previous one completed)" added in bug 1319987

this would be the changelog to the day before: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bdb2387396b4a74dfefb7c983733eed3625e906a&tochange=aeb3d0ca558f034cbef1c5a68bd07dd738611494

do you think it could be related to the patch from bug 1313398 landing in that timeframe?
Flags: needinfo?(jyavenard)
OS: Android → All
Hardware: Unspecified → All
Assignee: nobody → jyavenard
Blocks: 1319987
Flags: needinfo?(jyavenard)
Keywords: regression
this is very late in the 54 cycle, but I'm hoping that can still be uplifted
(In reply to [:philipp] from comment #7)
> do you think it could be related to the patch from bug 1313398 landing in
> that timeframe?

not directly, however it can increase the circumstances under which we re-initialise the decoder..
This is the #2 Windows topcrash in Nightly 20170602030204. It doesn't show up at all in Nightly 20170602100159. So the likely regression range is here:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bdb2387396b4a74dfefb7c983733eed3625e906a&tochange=aeb3d0ca558f034cbef1c5a68bd07dd738611494

Bug 1313398 (jya) and bug 1368837 (gsquelart) are the two bugs in that range that look most relevant, though I may be overlooking something.
Flags: needinfo?(jyavenard)
Flags: needinfo?(gsquelart)
Summary: Crash in mozilla::H264Converter::Decode → Crash in mozilla::H264Converter::Decode: MOZ_RELEASE_ASSERT(!mDecodePromiseRequest.Exists() && !mInitPromiseRequest.Exists())
I've submitted a fix.. not sure that there's more I can do at this stage!
Flags: needinfo?(jyavenard)
Flags: needinfo?(gsquelart)
From the crash report, the volume of crashes in 54 is very low. Given we are about to go to RC week, I prefer to let it ride the train and won't fix in 54.
Comment on attachment 8874191 [details]
Bug 1345342: Cancel pending requests.

https://reviewboard.mozilla.org/r/145616/#review149616
Attachment #8874191 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/8e78bd3e1e16
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
the signature is still present after this patch has landed: https://crash-stats.mozilla.com/signature/?build_id=%3E%3D20170606030207&version=55.0a1&signature=mozilla%3A%3AH264Converter%3A%3ADecode#reports
Status: RESOLVED → REOPENED
Flags: needinfo?(jyavenard)
Resolution: FIXED → ---
Depends on: 1370805
will be handled in bug 1370805.
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Flags: needinfo?(jyavenard)
Resolution: --- → FIXED
This is still present in the nightly of 20170608030205, and is the 
#2 windows topcrash.
The last report is 20170608030205, which doesn't include the fix.
You need to log in before you can comment on or make changes to this bug.