612099 - crash [@ nanojit::Assembler::prepareResultReg ] on HTC devices and ARM v6

Status: RESOLVED WORKSFORME

(Core Graveyard :: Nanojit, defect)

Description

[Scoobidiver (away)]

It is #11 top crasher in Fennec 4.0b3pre for the last week.

Signature	nanojit::Assembler::prepareResultReg
UUID	d7648c11-3d8c-4bf7-b173-5b3382101113
Time 	2010-11-13 19:34:55.699055
Uptime	64
Last Crash	167 seconds before submission
Install Age	193 seconds (3.2 minutes) since version was first installed.
Product	Fennec
Version	4.0b3pre
Build ID	20101113043324
Branch	2.0
OS	Linux
OS Version	0.0.0 Linux 2.6.29.6-aospMod #1 PREEMPT Sat Nov 13 14:45:59 EST 2010 armv6l
CPU	arm
CPU Info	
Crash Reason	SIGSEGV
Crash Address	0x0
User Comments	
App Notes 	nothumb Build
HTC HERO200
google/passion/passion/mahimahi:2.2.1/FRG83/60505:user/release-keys
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	nanojit::Assembler::prepareResultReg 	js/src/nanojit/LIR.h:780
1 	libxul.so 	nanojit::Assembler::asm_fop 	js/src/nanojit/NativeARM.cpp:2232
2 	libxul.so 	nanojit::Assembler::gen 	js/src/nanojit/Assembler.cpp:1703
3 	libxul.so 	nanojit::Assembler::compile 	js/src/nanojit/Assembler.cpp:1084
4 	libxul.so 	js::TraceRecorder::closeLoop 	js/src/jstracer.cpp:4417
5 	libxul.so 	js::TraceRecorder::closeLoop 	js/src/jstracer.cpp:4766
6 	libxul.so 	js::TraceRecorder::checkTraceEnd 	js/src/jstracer.cpp:4758
7 	libxul.so 	js::TraceRecorder::relational 	js/src/jstracer.cpp:9032
8 	libxul.so 	js::TraceRecorder::monitorRecording 	js/src/jsopcode.tbl:141
9 	libxul.so 	js::Interpret 	js/src/jsinterp.cpp:2669
10 	libxul.so 	js::Invoke 	js/src/jsinterp.cpp:665
11 	libxul.so 	js::ExternalInvoke 	js/src/jsinterp.cpp:881
12 	libxul.so 	JS_CallFunctionValue 	js/src/jsinterp.h:954
13 	libxul.so 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
14 	libxul.so 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:577
15 	libxul.so 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:132
16 	libxul.so 	libxul.so@0xd0fe87 	
17 	libxul.so 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1112
18 		@0x4d7ac34f 	
19 	libxul.so 	nsEventListenerManager::HandleEventInternal 	content/events/src/nsEventListenerManager.cpp:1208
20 	libxul.so 	nsEventTargetChainItem::HandleEvent 	content/events/src/nsEventListenerManager.h:146
21 	libxul.so 	nsEventTargetChainItem::HandleEventTargetChain 	content/events/src/nsEventDispatcher.cpp:311
22 	libxul.so 	nsEventDispatcher::Dispatch 	content/events/src/nsEventDispatcher.cpp:628
23 	libxul.so 	PresShell::HandleEventInternal 	layout/base/nsPresShell.cpp:6940
24 	libxul.so 	PresShell::HandlePositionedEvent 	layout/base/nsPresShell.cpp:6774
25 	libxul.so 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:6627
26 	libxul.so 	nsViewManager::HandleEvent 	view/src/nsViewManager.cpp:1092
27 	libxul.so 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:1070
28 	libxul.so 	HandleEvent 	view/src/nsView.cpp:161
29 	libxul.so 	nsWindow::DispatchEvent 	widget/src/android/nsWindow.cpp:576
30 	libxul.so 	nsWindow::OnMotionEvent 	widget/src/android/nsWindow.cpp:1052
31 	libxul.so 	nsWindow::OnGlobalAndroidEvent 	widget/src/android/nsWindow.cpp:724
32 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	widget/src/android/nsAppShell.cpp:288
33 	libxul.so 	nsBaseAppShell::DoProcessNextNativeEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:162
34 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:309
35 	libxul.so 	mozilla::dom::ContentParent::OnProcessNextEvent 	dom/ipc/ContentParent.cpp:561
36 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:576
37 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
38 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
39 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
40 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
41 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:181
42 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:191
43 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3682
44 	libxul.so 	GeckoStart 	toolkit/xre/nsAndroidStartup.cpp:131
45 	libc.so 	libc.so@0x115e7 	
46 	libc.so 	libc.so@0x110cb 	

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=nanojit%3A%3AAssembler%3A%3AprepareResultReg&version=Fennec%3A4.0b3pre

Comment 1

[Nicholas Nethercote [inactive]]

This looks awfully similar to bug 612011;  the first entry on the stack is different but if you look closely that's because of inlining.  In both bugs the problematic line is LIR.h:780.  The strange thing is that it looks like this:

778 Register getReg() {
779     NanoAssert(isInReg());
780     Register r = { sharedFields.regnum };
781     return r;
782 }

It's not obvious to me how line 780 could cause a seg fault.  Maybe the LIns* through which getReg() is called is NULL?  That would give a 0x0 address.  But if the LIns* was NULL I would expect the crash earlier, eg. in Assembler::gen(), because there are lots of method calls done on the LIns* before getReg() occurs.

Jacob, any ideas?

Comment 2

[Jacob Bramley [:jbramley]]

> It's not obvious to me how line 780 could cause a seg fault.  Maybe the LIns*
> through which getReg() is called is NULL?

As you said, the code would crash earlier if ins were NULL.
ins->isExtant() is called before asm_fop(ins).

> Jacob, any ideas?

Not really. I'm looking to see what the compiler does with getReg.
Is there any way that you can get the disassembly and the PC at the time
of the crash? I can't seem to reproduce this on the shell, with
jit-tests, but I only have ARMv7 devices handy and (so far) I've only
tried the JS shell.

It's also somewhat suspicious that all the failing devices are ARMv6
devices, though it really shouldn't affect that code, and I wouldn't
expect to see a seg fault if we're mistakenly running ARMv7 code.

I'll have a bit more of a dig around.

Comment 3

[Jacob Bramley [:jbramley]]

My tool-chain actually didn't generate a symbol for getReg on an
optimized build (even with -g), so I built with
__attribute__((noinline)) on getReg to force it. This might change
things a bit, but it revealed the following implementation of getReg:

Dump of assembler code for function nanojit::LIns::getReg():
   0x0017c5a8 <+0>:     ldrb    r0, [r0]
   0x0017c5ac <+4>:     lsr     r0, r0, #1
   0x0017c5b0 <+8>:     bx      lr

(The non-optimized disassembly is huge and much harder to read.)

The code appears valid. On entry, r0 will hold 'this', which will be a
pointer to an LIns. The sharedFields struct is the first element of
LIns, so the offset is 0. The byte load (ldrb) and logical shift (lsr)
correctly extract the regnum field.

There is clearly only one load instruction here, so if the segmentation
fault is indeed caused by getReg, it is occurring in one of the
following conditions:

  • 'r0' is not a valid pointer. Thus, 'this' is not a valid pointer.
    We've already decided that this shouldn't be happening.

  • The compiler is getting something wrong with the in-lining. This is
    very unlikely, but cannot be ruled out at this stage.

  • The back-trace is wrong, perhaps due to in-lining, and the true
    fault is somewhere else.

  • Some other case that I haven't thought of.

I'll look at the disassembly of methods that call getReg to try to guess
at what might be happening, but it's hard to draw conclusions without
reproducing the problem, particularly as it's apparently ARMv6-only.

Comment 4

[Jacob Bramley [:jbramley]]

There's nothing untoward in my compiler's in-lining of getReg in findRegFor, at least. To find out more without wild speculation, we really need some disassembly of some known-bad code.

Comment 5

[Jacob Bramley [:jbramley]]

The failing nightly builds are available (http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/), but they don't have symbols (or crash reporter helpers bundled with some other nightly builds). The binaries might be quite useful if they had symbols. Does anyone know how I can get them?

Comment 6

[Robert Sayre]

It's not clear why we would spend time on ARMv6 at this time in the release cycle, when aren't planning to ship on anything but ARMv7 devices in the near future. There are probably better things to spend time on.

Comment 7

[Mike Shaver (:shaver emeritus)]

Stuart tells me that we're supposed to be detecting ARMv6 at startup and giving an error to the user. Is this crash happening before that detection code runs? uptime of 64 is pretty small.

Comment 8

[Robert Sayre]

(In reply to comment #7)
> Stuart tells me that we're supposed to be detecting ARMv6 at startup and giving
> an error to the user. Is this crash happening before that detection code runs?
> uptime of 64 is pretty small.

Since the App Notes say "nothumb", I think we are seeing crashes from the "experimental ARMv6" builds listed here:

https://wiki.mozilla.org/Mobile/Platforms/Android

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #8)
> (In reply to comment #7)
> 
> Since the App Notes say "nothumb", I think we are seeing crashes from the
> "experimental ARMv6" builds listed here:
> 
> https://wiki.mozilla.org/Mobile/Platforms/Android

That's correct, and those builds are unsupported and not blocking final. Fixes are obviously good, but let's not burn resources here.

Comment 10

[Mike Shaver (:shaver emeritus)]

We should probably look at how to filter those out of crash-stats.

Comment 11

[Scoobidiver (away)]

There have been no crashes for the last four weeks.
I close it as WFM.