Assert failure in js::jit::JitFrameIterator::exitFrame while starting "Banana Bread" WebGL demo

RESOLVED DUPLICATE of bug 1150783

Status

()

Core
JavaScript Engine: JIT
RESOLVED DUPLICATE of bug 1150783
3 years ago
3 years ago

People

(Reporter: q1, Unassigned)

Tracking

39 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
While attempting to start the "Banana Bread" WebGL demo at https://developer.mozilla.org/en-US/demos/detail/bananabread , Firefox crashed with an assert fail. This is under 39.0 debug (my build with no modifications). Here's the stack:

>	xul.dll!js::jit::JitFrameIterator::exitFrame() Line 68	C++
 	xul.dll!js::jit::LazyLinkTopActivation(JSContext * cx) Line 447	C++
 	2cb16e1d()	Unknown
 	[Frames below may be incorrect and/or missing]	
 	1ecfcaeb()	Unknown
 	1ece14d1()	Unknown
 	1e890edb()	Unknown
 	0117a8de()	Unknown
 	0115b790()	Unknown
 	000bcbb0()	Unknown
 	02c24320()	Unknown
 	1ecdde43()	Unknown

This crash is completely reproducible (I've done it 4 times). Just start the demo and ask for the "low resolution" version. Then wait a few seconds after the play screen appears for it to crash.
LazyLinkTopActivation so NI from Hannes but feel free to forward if it's unrelated.
Flags: needinfo?(hv1989)
I couldn't reproduce locally. Therefore I will need to ask some extra questions

1) Is it reproducible on newest debug build: 
http://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux-debug/latest/
http://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/latest/
http://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-debug//latest/ 

2) Can you provide a crash dump? Go to about:crashes. That will give a list of all crash reports you have.
Please provide the link to the one with "LazyLinkTopActivation"
Flags: needinfo?(hv1989)
(Reporter)

Comment 3

3 years ago
(In reply to Hannes Verschore [:h4writer] from comment #2)
> I couldn't reproduce locally. Therefore I will need to ask some extra
> questions
> 
> 1) Is it reproducible on newest debug build: 
> http://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-linux-debug/latest/
> http://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-macosx64/latest/
> http://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-win32-debug//latest/ 
> 
> 2) Can you provide a crash dump? Go to about:crashes. That will give a list
> of all crash reports you have.
> Please provide the link to the one with "LazyLinkTopActivation"

For privacy reasons I won't provide a dump, but I have saved two from the VS debugger, and will answer questions about them. I'll try the latest debug build soon and report what happens.
(Reporter)

Comment 4

3 years ago
There appears to be a problem with the GPG signature for https://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-debug//latest/firefox-43.0a1.en-US.win32.checksums . It is signed by key 0x50FA58BC , which doesn't exist on either https://gpg.mozilla.org/ or http://pgp.mit.edu/ . Why wasn't this signed by key 0x5E9905DB ?
(Reporter)

Updated

3 years ago
Flags: needinfo?(hv1989)
Signed? I thought checksums were only a hash over the full binary. But that can be my ignorance.
Flags: needinfo?(hv1989)
(Reporter)

Comment 6

3 years ago
(In reply to Hannes Verschore [:h4writer] from comment #5)
> Signed? I thought checksums were only a hash over the full binary. But that
> can be my ignorance.

https://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-debug//latest/firefox-43.0a1.en-US.win32.checksums contains SHA512 hashes for all the files. And https://archive.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-debug//latest/firefox-43.0a1.en-US.win32.checksums.asc contains a GPG signature for .checksums, so that we can verify whether .checksums is authentic. But the .asc file signature was made by the unknown key 0x50FA58BC instead of the well-attested key 0x5E9905DB . You can use gpg --verify to see for yourself.
Flags: needinfo?(hv1989)
(Reporter)

Comment 7

3 years ago
This demo works without error on 40.0 debug.
(In reply to q1 from comment #7)
> This demo works without error on 40.0 debug.

Thanks for checking!

In that case I assume this bug is probably bug 1150783, which has a similar backtrace and has landed in 40.0
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(hv1989)
Resolution: --- → DUPLICATE
Duplicate of bug: 1150783
You need to log in before you can comment on or make changes to this bug.