Closed Bug 871290 Opened 7 years ago Closed 6 years ago

crash in js::ion::Assembler::TraceJumpRelocations

Categories

(Core :: JavaScript Engine, defect, critical)

23 Branch
ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla25
Tracking Status
firefox22 --- unaffected
firefox23 + fixed
firefox24 + fixed
firefox25 --- fixed
fennec 23+ ---

People

(Reporter: scoobidiver, Assigned: mjrosenb)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [native-crash])

Crash Data

Attachments

(1 file)

With the below stack trace, it first showed up in 23.0a1/20130509. The regression range might be (low volume):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b980d32c366f&tochange=ea059733677c

Signature 	js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&) More Reports Search
UUID	99075260-7dae-485d-8fe8-93b112130512
Date Processed	2013-05-12 16:46:15
Uptime	6182
Last Crash	2.6 weeks before submission
Install Age	1.7 hours since version was first installed.
Install Time	2013-05-12 15:03:19
Product	FennecAndroid
Version	23.0a1
Build ID	20130512030908
Release Channel	nightly
OS	Android
OS Version	0.0.0 Linux 3.0.8-g44ffd6a #1 SMP PREEMPT Fri Jul 6 03:57:28 CDT 2012 armv7l verizon/targa_vzw/cdma_targa:4.1.2/JZO54K/20121116:user/release-keys
Build Architecture	arm
Build Architecture Info	ARMv0
Crash Reason	SIGSEGV
Crash Address	0xe584bffc
App Notes 	
AdapterDescription: 'Imagination Technologies -- PowerVR SGX 540 -- OpenGL ES 2.0 build 1.8@796887 -- Model: XT875, Product: targa_vzw, Manufacturer: Motorola, Hardware: mapphone_cdma'
GL Layers! EGL? EGL+ GL Context? GL Context+ GL Layers+ 
Motorola XT875
verizon/targa_vzw/cdma_targa:4.1.2/JZO54K/20121116:user/release-keys
Processor Notes 	sp-processor07_phx1_mozilla_com_14837:2012; exploitability tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	Imagination Technologies
Adapter Device ID	PowerVR SGX 540
Device	Motorola XT875
Android API Version	16 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libxul.so 	js::ion::Assembler::TraceJumpRelocations 	IonCode.h:115
1 	libxul.so 	js::ion::IonCode::trace 	Ion.cpp:482
2 	libxul.so 	js::GCMarker::processMarkStackOther 	Marking.cpp:1129
3 	libxul.so 	ScanShape 	Marking.cpp:838
4 	libxul.so 	js::GCMarker::drainMarkStack 	Marking.cpp:1363
5 	libxul.so 	IncrementalCollectSlice 	jsgc.cpp:3780 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3AAssembler%3A%3ATraceJumpRelocations%28JSTracer*%2C+js%3A%3Aion%3A%3AIonCode*%2C+js%3A%3Aion%3A%3ACompactBufferReader%26%29
It's #5 crasher in 23.0a2 and #7 in 24.0a1.
tracking-fennec: --- → ?
Keywords: topcrash
Naveed, we need an assignee for this
tracking-fennec: ? → 23+
Flags: needinfo?(naveed)
I can take a look soon.
Assignee: general → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(naveed)
Crash Signature: [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] → [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode> ]
Crash Signature: [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode> ] → [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode>]
It's #55 crasher in 21.0, #88 in 22.0b3, #3 in 23.0a2, and #5 in 24.0a1.
It's now even #1 top crasher in 23.0a2.

Two comments talk about scrolling:
"scrolling on reddit.."
"Scrolling (slowly) while reading an article on atlantic.com. I do not know if the page had finished loading. There was enough there for the page to look complete and allow me to read the article."
Scoobidiver: there are no crashes with more recent 24.0a1 builds, right? The last build I see is from May but I'm not sure if I'm using Socorro correctly.
(In reply to Jan de Mooij [:jandem] from comment #6)
> Scoobidiver: there are no crashes with more recent 24.0a1 builds, right? The
> last build I see is from May but I'm not sure if I'm using Socorro correctly.
You're partially right. The latest crash with the js::ion::Assembler::TraceJumpRelocations signature happened in 24.0a1/20130525062525 but the latest one with the MarkInternal<js::ion::IonCode> signature (added to this bug because it has only one more frame - ARMv6 version?) occurred in 24.0a1/20130605031156. See https://crash-stats.mozilla.com/report/list?signature=MarkInternal%3Cjs%3A%3Aion%3A%3AIonCode%3E

Maybe it's fixed in the trunk and not in Aurora. In that case, the working range might be (assumption: fixed after 24.0a1/20130605, 3-day range):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f9ba85eb61c&tochange=6006abb39d8e
(In reply to Scoobidiver from comment #7)
> Maybe it's fixed in the trunk and not in Aurora.
It seems the signature has morphed again. See https://crash-stats.mozilla.com/report/list?signature=js%3A%3Agc%3A%3AMarkIonCode%28JSTracer*%2C+js%3A%3AEncapsulatedPtr%3Cjs%3A%3Aion%3A%3AIonCode%2C+unsigned+int%3E*%2C+char+const*%29
Crash Signature: [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode>] → [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode>] [@ js::gc::MarkIonCode(JSTracer*, js::EncapsulatedPtr<js::ion::IonCode, unsigned int>*, char const*) ]
I discussed this with mjrosenb and decoder on IRC. decoder's fuzzer hit this crash on ARM, so hopefully he will be able to get us a testcase soon.

mjrosenb wrote a patch that may fix the problem, hopefully once we have a testcase we can see if that patch fixes it and land it.
couldn't think of a more descriptive name.  this passed jit-tests, so it shouldn't cause any regressions.  I haven't tested on armv6 yet.
Assignee: jdemooij → mrosenberg
Attachment #761074 - Flags: review?(Jacob.Bramley)
Attachment #761074 - Flags: review?(Jacob.Bramley) → review+
https://hg.mozilla.org/mozilla-central/rev/7f58c0937b1d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Crash Signature: [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode>] [@ js::gc::MarkIonCode(JSTracer*, js::EncapsulatedPtr<js::ion::IonCode, unsigned int>*, char const*) ] → [@ js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&)] [@ MarkInternal<js::ion::IonCode>] [@ js::gc::MarkIonCode(JSTracer*, js::EncapsulatedPtr<js::ion::IonCode, unsigned int>*, char const*) ] [@ js::g…
:mjrosenb, can you nom it for 23 please?
Flags: needinfo?(mrosenberg)
Comment on attachment 761074 [details] [diff] [review]
/home/mjrosenb/patches/bug871290-r0.patch

om nom nom
[Approval Request Comment]
Bug caused by (feature/regressing bug #): 805241
User impact if declined: crashes on malicious web sites
Testing completed (on m-c, etc.): sitting on m-c for a few days now
Risk to taking this patch (and alternatives if risky): there may be some features that we won't be able to add in c++ due to a slight restriction on what data can be accessed-- I can't imagine this will ever affect anything we could want to write
String or IDL/UUID changes made by this patch:
Attachment #761074 - Flags: approval-mozilla-aurora?
Attachment #761074 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Marty Rosenberg [:mjrosenb] from comment #14)
> Testing completed (on m-c, etc.): sitting on m-c for a few days now
Unfortunately at the same time, the patch of bug 678037 landed. It had been hidden by its side effects for a few builds. See https://crash-stats.mozilla.com/report/list?signature=js%3A%3Agc%3A%3AMarkGCThingRoot%28JSTracer*%2C+void**%2C+char+const*%29
Status: RESOLVED → REOPENED
Flags: needinfo?(mrosenberg)
Resolution: FIXED → ---
Because of bug 884300, there's now a full stack trace. See bp-c6fcb362-6504-4777-9e14-ccb9f2130621:
Frame 	Module 	Signature 	Source
0 	libxul.so 	js::ion::Assembler::TraceJumpRelocations 	js/src/ion/IonCode.h:115
1 	libxul.so 	js::ion::IonCode::trace 	js/src/ion/Ion.cpp:482
2 	libxul.so 	js::GCMarker::processMarkStackOther 	js/src/gc/Marking.cpp:1129
3 	libxul.so 	js::GCMarker::drainMarkStack 	js/src/gc/Marking.cpp:1363
4 	libxul.so 	IncrementalCollectSlice 	js/src/jsgc.cpp:3780
5 	libxul.so 	GCCycle 	js/src/jsgc.cpp:4422
6 	libxul.so 	Collect 	js/src/jsgc.cpp:4581
7 	libxul.so 	js::GC 	js/src/jsgc.cpp:4491
8 	libxul.so 	mozilla::dom::workers::WorkerPrivate::GarbageCollectInternal 	dom/workers/WorkerPrivate.cpp:4111
9 	libxul.so 	GarbageCollectRunnable::WorkerRun 	dom/workers/WorkerPrivate.cpp:1400
10 	libxul.so 	mozilla::dom::workers::WorkerRunnable::Run 	dom/workers/WorkerPrivate.cpp:1638
11 	libxul.so 	mozilla::dom::workers::WorkerPrivate::DoRunLoop 	dom/workers/WorkerPrivate.cpp:2762
12 	libxul.so 	WorkerThreadRunnable::Run 	dom/workers/RuntimeService.cpp:534
13 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
14 	libxul.so 	NS_ProcessNextEvent 	obj-firefox/xpcom/build/nsThreadUtils.cpp:238
15 	libxul.so 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:265
16 	libnss3.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:204
17 	libc.so 	libc.so@0xe3da 	
18 	libc.so 	libc.so@0xdac6
It's #3 top crasher in 23.0b1.
Since 24.0a1/20130615 when the patch landed with others, it's a lower volume crash, only four crashes.

(In reply to Jan de Mooij [:jandem] from comment #9)
> decoder's fuzzer hit this crash on ARM, so hopefully he will be able to get us a 
> testcase soon.
Can we get that testcase?
Flags: needinfo?(choller)
We don't have a testcase for this. All crashes that I saw were not reproducible. I talked with Marty about adding a debug-only function for testing, that makes such conditions more reproducible but we don't have this yet.
Flags: needinfo?(choller)
A comment says: "I was actually trying to force a crash by repeatedly clicking the back button out of an email link of a link ."
Still #1 top crasher in 23.0b2 but no crashes in 24.0a2 and one in 25.0a1.
(In reply to Scoobidiver from comment #22)
> Still #1 top crasher in 23.0b2 but no crashes in 24.0a2 and one in 25.0a1.

Hasn't this landed on 23 as well?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #23)
> Hasn't this landed on 23 as well?
The patch in this bug hasn't fixed the issue (see comment 16). It's another unknown patch that has fixed it.
If we don't know what "fixed" this then it's not even clear that it's fixed at all because this bug is highly fragile, minor changes can make repros fail easily.

Marty, some time ago you mentioned adding a debug function to find problems like this (pool problems I think) easier in the shell. Can we add that and try more fuzzing then?
Flags: needinfo?(mrosenberg)
the last build to crash in js::ion::Assembler::TraceJumpRelocations(JSTracer*, js::ion::IonCode*, js::ion::CompactBufferReader&) are from build 20130701142603. 

There are crashes [@ MarkInternal<js::ion::IonCode>] with the latest betas.

Should a separate bug be split off for the crashing signature.
Blocks: 893376
(In reply to Scoobidiver from comment #22)
> no crashes in 24.0a2 and one in 25.0a1.
It has been back since 25.0a1/20130710.
Blocks: 894251
Not a topcrasher for FF23, removing tracking and keyword.
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #28)
> Not a topcrasher for FF23, removing tracking and keyword.
???? It's #2 top crasher in 23.0b4.
My mistake, I was looking at Firefox, not Fennec stats
Marty, do we have any idea what's going on here? Is there anything we can do to help the fuzzers? We need to fix this.
A comment says: "Hate to say it but FFox has been acting ''wonky'' since the Google keyboard (touch screen) driver update. Intermittent: crashes, only loading the left (slightly more than) half of the screen, freezing... What I'm doing, what site at the time, doesn't seem to matter."
No longer blocks: 893376
Marty and I are debugging this now on Try (see also bug 894251).
(In reply to Jan de Mooij [:jandem] from comment #33)
> Marty and I are debugging this now on Try (see also bug 894251).

We tracked down this one, will be fixed in bug 894251. This should hopefully stop the intermittent crashes we're currently seeing on inbound/central. The bug has been there since Ion was first released in 18 but is unlikely to cause the beta topcrashes -- still, we really want to land that fix on beta and see if it helps some.
No longer blocks: 894251
Depends on: 894251
(In reply to Jan de Mooij [:jandem] from comment #34)
> The bug has been there since Ion was first released in 18 but is unlikely to
> cause the beta topcrashes -- 

After looking at the stack traces again I'm not so sure anymore these are unrelated. Almost all stack traces point to GCs from a DOM worker thread. Workers have their own JSRuntime and hence get their own pre-compiled/shared stubs, so it's possible creating many workers makes us more likely to hit bug 894251.

So I hope this is bug 894251, but it's hard to know for sure at this point.
Flags: needinfo?(mrosenberg)
(In reply to Jan de Mooij [:jandem] from comment #35)
> So I hope this is bug 894251, but it's hard to know for sure at this point.
There have been no crashes since 25.0a1/20130727 but it previously skipped up to two builds so let's wait a little more to confirm.
Here is a recent crash report: bp-74b4f5ef-0415-4527-967a-7e84c2130730.
(In reply to Scoobidiver from comment #37)
> Here is a recent crash report: bp-74b4f5ef-0415-4527-967a-7e84c2130730.

That's a different signature though: TraceJumpRelocations vs TraceDataRelocations.
> That's a different signature though: TraceJumpRelocations vs
> TraceDataRelocations.

Oh wow, I didn't even notice that.  Is it possible that this is related to the improper use of ma_mov (as opposed to ma_movPatchable) in one of the data paths?
23+ ship has sailed. Need to re-triage this.
tracking-fennec: 23+ → ?
(In reply to Kevin Brosnan [:kbrosnan] from comment #40)
> 23+ ship has sailed. Need to re-triage this.

Er, why? This should be fixed for 23.0b10.
I was just mass resetting flags after FxA triage. We decided that most open bugs marked 23+ were not going to make 23. 

Looking at crash stats this looks to be fixed.
Status: REOPENED → RESOLVED
tracking-fennec: ? → 23+
Closed: 7 years ago6 years ago
Resolution: --- → FIXED
Let's consider the top crasher fixed although there are still some crashes in Nightly.
Target Milestone: mozilla24 → mozilla25
You need to log in before you can comment on or make changes to this bug.