bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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

RESOLVED FIXED in Firefox 55



Audio/Video: Playback
a year ago
9 months ago


(Reporter: kanru, Assigned: jya)


({crash, regression})

52 Branch
crash, regression
Dependency tree / graph

Firefox Tracking Flags

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


(crash signature)

MozReview Requests


Submitter Diff Changes Open Issues Last Updated
Error loading review requests:


(1 attachment)



a year ago
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)
status-firefox54: --- → affected
status-firefox55: --- → affected
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)

Comment 4

a year ago
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

Comment 7

10 months ago
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


10 months ago
Assignee: nobody → jyavenard
Blocks: 1319987
Flags: needinfo?(jyavenard)
Keywords: regression

Comment 8

10 months ago
this is very late in the 54 cycle, but I'm hoping that can still be uplifted
tracking-firefox54: --- → ?

Comment 9

10 months ago
(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..
Comment hidden (mozreview-request)
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:


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())

Comment 12

10 months ago
I've submitted a fix.. not sure that there's more I can do at this stage!
Flags: needinfo?(jyavenard)
Flags: needinfo?(gsquelart)

Comment 13

10 months ago
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.
status-firefox54: affected → wontfix
tracking-firefox54: ? → -

Comment 14

10 months ago
Comment on attachment 8874191 [details]
Bug 1345342: Cancel pending requests.

Attachment #8874191 - Flags: review+
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Blocks: 1370005

Comment 20

10 months ago
Last Resolved: 10 months ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
status-firefox53: --- → unaffected
status-firefox-esr52: --- → unaffected

Comment 21

10 months ago
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-firefox55: fixed → affected
Flags: needinfo?(jyavenard)
Resolution: FIXED → ---
Depends on: 1370805

Comment 22

10 months ago
will be handled in bug 1370805.
Last Resolved: 10 months ago10 months ago
Flags: needinfo?(jyavenard)
Resolution: --- → FIXED


10 months ago
status-firefox55: affected → fixed
This is still present in the nightly of 20170608030205, and is the 
#2 windows topcrash.

Comment 24

9 months ago
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.