475916 - crash when click on upper right hand corner search box of facebook [@ TraceRecorder::set]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[pekkle]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre

After clicking on the search box of http://www.facebook.com at upper right hand corner, firefox will crash.

Crash even with new profile with no plugin, but it will not crash in Safe Mode.

Reproducible: Always

Steps to Reproduce:
1.browse to http://www.facebook.com and logon
2.click on the search box on the upper right hand corner
3.crash without typing anything
Actual Results:  
crashed

Expected Results:  
allow to type the search string

start appear in hourly build 20090128 (I am using 20090128190032)

Comment 1

[IU]

No crash on XP.  You should post your crash report link.

Comment 2

[pekkle]

Attachment: crash image

No crash report being submitted :(

Comment 3

[pekkle]

Theme=classic/1.0
StartupTime=1233221823
ServerURL=https://crash-reports.mozilla.com/submit
Add-ons=[e-mail]:1.0,{972ce4c6-7e08-4474-a285-3208198ce6fd}:3.2a1pre
BuildID=20090128190032
ProductName=Firefox
Vendor=Mozilla
Version=3.2a1pre
InstallTime=1233213508
URL=http://www.facebook.com/home.php?
CrashTime=1233221881
SecondsSinceLastCrash=779


it's the information get from the minidumps folder

Comment 4

[IU]

If no one shows up with windows 2000 and able to reproduce, you may have to manually get a stack trace.  See this article for how: https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_WinDbg

Be sure to disable the Java Quick Starter extension first, as it prevents Firefox from loading via the debugger.

When opening the executable in the debugger (per the instructions in the linked article), if you have more than one Firefox profile, you need to use the -p option to specify the profile name on the "Arguments:" line, otherwise Firefox will not load.

Comment 5

[pekkle]

Try 20090128 official nightly, and it do not crash.

It may be new bug introduced to the hourly build. I will wait for the next official nightly tomorrow, and try to reproduce the problem again.

Comment 6

[Myzar]

I crash with the official nightly too and i'm under windows 7

http://crash-stats.mozilla.com/report/index/a3c90a59-0052-4906-8e38-9dc472090129

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre (.NET CLR 3.5.30729)

Comment 7

[pekkle]

I could reproduce in XP SP3, too.

http://crash-stats.mozilla.com/report/pending/5ace35f1-5e25-41a0-bd40-308d82090129

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090129033611

Comment 8

[Kenn]

I can reproduce this consistently with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090129 FireFox/3.0.4 - Build ID: 20090129033611

Crash report id (I think) bp-bad9b05e-9ce9-43c0-aa57-8afbf2090129

Comment 9

[Mike Shaver (:shaver emeritus)]

Kenn: Wait, you can reproduce it with Firefox 3.0.4?  If so, that's not this bug, since the tracerecorder isn't in 3.0.4.  That crash report is from 3.2a1, though, so it looks like it fits.

Blocking.  Can someone find a regression range?  That would be super-helpful!

Comment 10

[IU]

(In reply to comment #9)
> Kenn: Wait, you can reproduce it with Firefox 3.0.4?

No he can't.  Look at the string inside the parenthesis.

Comment 11

[Kenn]

(In reply to comment #9)
> Kenn: Wait, you can reproduce it with Firefox 3.0.4?  If so, that's not this
> bug, since the tracerecorder isn't in 3.0.4.  That crash report is from 3.2a1,
> though, so it looks like it fits.
> 
> Blocking.  Can someone find a regression range?  That would be super-helpful!

No - I'm not using 3.0.4, that is in my build id to spoof my corp's sites that don't accept 3.2a1pre as a valid browser

Comment 12

[Honza Bambas (:mayhemer)]

pekkle, or anyone: are you using any extensions or do you have any specific
configuration? I cannot reproduce with trunk build 2 hours old from now
[Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko
Minefield/3.2a1pre ID:20090129210354]

Comment 13

[Kenn]

I just reproduced it with this hourly build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090129 FireFox/3.0.4 - Build ID: 20090129121519  which, if I read the build id properly,. was created at 12:15:19 today.  It crashed but didn't create a crash report.


Kenn

Comment 14

[Kenn]

Just tried in safe mode - no crash with last hourly

Comment 15

[Kenn]

I just tried disabling all of my extensions one by one - and it does it with them disabled.  Haven't tried the plug-ins yet.

Comment 16

[Honza Bambas (:mayhemer)]

Kenn: what options you used when starting safe mode? what extensions do you have installed? what firefox theme are you using?

Would you be willing to find the first hourly build that crashes for you? According to comment 5, 20090128 official nightly should yet not crash.

Comment 17

[Myzar]

i can reproduce this crash with a fresh profile and no extensions , i haven't tried in safe mode, turning jit.content to false stops the crash.

Comment 18

[Kenn]

(In reply to comment #16)
> Kenn: what options you used when starting safe mode? what extensions do you
> have installed? what firefox theme are you using?
> 
> Would you be willing to find the first hourly build that crashes for you?
> According to comment 5, 20090128 official nightly should yet not crash.

just used the safe mode from the windows start menu.
I am using Noia 3.57

Comment 19

[Kenn]

(In reply to comment #17)
> i can reproduce this crash with a fresh profile and no extensions , i haven't
> tried in safe mode, turning jit.content to false stops the crash.

I just turned jit content to false and it stopped crashing.

Comment 20

[Kenn]

(In reply to comment #19)
> (In reply to comment #17)
> > i can reproduce this crash with a fresh profile and no extensions , i haven't
> > tried in safe mode, turning jit.content to false stops the crash.
> 
> I just turned jit content to false and it stopped crashing.

this hourly crashes with jit content turned on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090128 FireFox/3.0.4 - Build ID: 20090128174802

Can't find the ones before that....

Comment 21

[Andreas Gal :gal]

Breakpoint 1, TraceRecorder::record_JSOP_NEXTITER (this=0x1c0639a0) at ../../../js/src/jstracer.cpp:7898
7898	MITIVE(iterobj_val))
(gdb) c
Continuing.

Breakpoint 1, TraceRecorder::record_JSOP_NEXTITER (this=0x17e79b10) at ../../../js/src/jstracer.cpp:7898
7898	MITIVE(iterobj_val))
(gdb) c
Continuing.

Breakpoint 1, TraceRecorder::record_JSOP_NEXTITER (this=0x17e79b10) at ../../../js/src/jstracer.cpp:7898
7898	MITIVE(iterobj_val))
(gdb) c
Continuing.

Breakpoint 1, TraceRecorder::record_JSOP_NEXTITER (this=0x17e79b10) at ../../../js/src/jstracer.cpp:7898
7898	MITIVE(iterobj_val))
(gdb) c
Continuing.

Breakpoint 1, TraceRecorder::record_JSOP_NEXTITER (this=0x17e79b10) at ../../../js/src/jstracer.cpp:7898
7898	MITIVE(iterobj_val))
(gdb) c
Continuing.

Breakpoint 1, TraceRecorder::record_JSOP_NEXTITER (this=0x17e924c0) at ../../../js/src/jstracer.cpp:7898
7898	MITIVE(iterobj_val))
(gdb) enable 2
(gdb) c
Continuing.

Breakpoint 2, js_Interpret (cx=0x2208fe00) at ../../../js/src/jsinterp.cpp:2948
2948	                fp->imacpc = NULL;
3: fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
2: fp = (JSStackFrame *) 0x220fcd88
1: op = JSOP_STOP
(gdb) enable 3
(gdb) c
Continuing.

Breakpoint 3, js_Interpret (cx=0x2208fe00) at ../../../js/src/jsinterp.cpp:3083
3083	                BRANCH(len);
3: fp.imacpc = (jsbytecode *) 0x0
2: fp = (JSStackFrame *) 0x220fcd88
1: op = JSOP_IFNE
(gdb) enable 4
(gdb) c
Continuing.

We finish the above imacro and then hit the IFNE, which makes us look for trees for the target address:

Breakpoint 4, js_RecordLoopEdge (cx=0x2208fe00, r=0x17e924c0, inlineCallCount=@0xbfffc2f8) at ../../../js/src/jstracer.cpp:3563
3563	    if (OBJ_SCOPE(JS_GetGlobalForObject(cx, cx->fp->scopeChain))->title.ownercx != cx) {
(gdb) display cx.fp.imacpc
4: cx.fp.imacpc = (jsbytecode *) 0x0
(gdb) n
3568	    JSTraceMonitor* tm = &JS_TRACE_MONITOR(cx);
4: cx.fp.imacpc = (jsbytecode *) 0x0

We find one and run it.

3638	    VMSideExit* lr = js_ExecuteTree(cx, f, inlineCallCount, &innermostNestedGuard);
4: cx.fp.imacpc = (jsbytecode *) 0x0
(gdb) 
3639	    if (!lr) {
4: cx.fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) p cx.fp.regs.pc
$42 = (jsbytecode *) 0x3f437a "\f?I?"

It side-exits inside an imacro (pc points into imacro, imacpc is set).

(gdb) n
3644	    switch (lr->exitType) {
4: cx.fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) 
3667	        debug_only_v(printf("exit_type=%d\n", lr->exitType);)
4: cx.fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) 
3668	        js_AbortRecording(cx, "Inner tree not suitable for calling");
4: cx.fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) 
3669	        return false;
4: cx.fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) 
3681	tatic bool
4: cx.fp.imacpc = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) 
js_MonitorLoopEdge (cx=0x2208fe00, inlineCallCount=@0xbfffc2f8) at ../../../js/src/jstracer.cpp:4124
4124	JS_ASSERT(!tm->recorder);
(gdb) 
4127	if (tm->reservedDoublePoolPtr < (tm->reservedDoublePool + MAX_NATIVE_STACK_SLOTS) &&
(gdb) 
4133	JSObject* globalObj = JS_GetGlobalForObject(cx, cx->fp->scopeChain);
(gdb) 
4134	uint32 globalShape = -1;
(gdb) 
4135	SlotList* globalSlots = NULL;
(gdb) 
4137	if (!js_CheckGlobalObjectShape(cx, tm, globalObj, &globalShape, &globalSlots))
(gdb) p cx.fp.regs.pc
$43 = (jsbytecode *) 0x3f437a "\f?I?"
(gdb) p cx.fp.imacpc
$44 = (jsbytecode *) 0x222b2443 "L\b??MT"
(gdb) n
4140	jsbytecode* pc = cx->fp->regs->pc;
(gdb) 
4142	if (oracle.getHits(pc) >= 0 && 
(gdb) p pc
$45 = (jsbytecode *) 0x3f437a "\f?I?"
(gdb) n
4148	Fragment* f = getLoop(tm, pc, globalShape);
(gdb) p pc
$46 = (jsbytecode *) 0x3f437a "\f?I?"
(gdb) n
4149	if (!f)
(gdb) p f
$47 = (class nanojit::Fragment *) 0x1d5be384

Here is where it gets bizarre. We are inside an imacro still and we seem to have a fragment for the imacro location:

(gdb) p f->ip
$48 = (const void *) 0x3f437a
(gdb) x/10x f->ip
0x3f437a <nextiter_imacros+18>:	0x0c	0xe7	0x49	0xc3	0x00	0x00	0xb8	0x00
0x3f4382 <iter_imacros+2>:	0x3f	0xe3
(gdb) p (JSOp)*(unsigned char*)f->ip
$57 = JSOP_DUP
(gdb) p (JSOp)((unsigned char*)f->ip)[1]
$58 = JSOP_HOLE
(gdb) p (JSOp)((unsigned char*)f->ip)[2]
$59 = JSOP_STRICTNE
(gdb) p (JSOp)((unsigned char*)f->ip)[3]
$60 = JSOP_STOP
(gdb)

Comment 22

[Andreas Gal :gal]

Attachment: patch

When invoking an inner tree there is no guarantee we land on a loop header again when we come out of that inner tree, so don't try to record or trigger traces there.

Comment 23

[Andreas Gal :gal]

Isn't there some kind of policy that we get a free facebook shirt if we make facebook.com not crash horribly? If there is not such policy, there should be one =)

Comment 24

[Andreas Gal :gal]

Attachment: v2

Be less pessimistic and allow recording of an inner tree as long we are still parked on the inner tree loop header. Otherwise bolt to the interpreter. This makes our trace-tests happy, which check that we immediate record and don't incur additional interpreter round-trips in between. No perf overhead on SS (might be a slight win).

Comment 25

[David Anderson [:dvander] - inactive, e-mail if emergency]

Comment on attachment 359698 [details] [diff] [review]
v2

stealing r? on request

Comment 26

[Andreas Gal :gal]

Pushed to TM. We will try to get this into mozilla central tonight.

http://hg.mozilla.org/tracemonkey/rev/5ce67a3a2bd0

Comment 27

[Michael]

I get this crash on both OS X and Windows XP.  The following are crash reports for it:

OS X:
fbe45709-2cec-4ecd-8d2a-620a02090130	1/30/09	5:55 PM
cccc95b2-0fdb-44b4-9f1a-346e42090130	1/30/09	5:54 PM
98e860b6-77e0-4de2-90a4-580002090130	1/30/09	8:42 AM
6e52635f-73d3-4cbe-a298-6d0672090130	1/30/09	12:53 AM
da6470ec-039f-4b52-a7fe-d364c2090130	1/30/09	12:53 AM
241af91b-a043-4e79-9cc8-886912090129	1/29/09	11:19 PM
1ea842a0-8587-43b5-b186-48f1a2090129	1/29/09	8:46 PM

XP:
d568783e-b6f4-4f2e-ae27-da66b2081210    12/10/2008    11:29 AM

Note: this is the same bug I reported in Bug 476124

Michael

Comment 28

[Michael]

Also, I did not get the issue before the 1/29 crash, so it would be the nightly built most recently before that crash.

Comment 29

[pekkle]

BTW, when will the patch be applied to mozilla central nightly? Still crashing with the latest build. :(

Comment 30

[Andreas Gal :gal]

Yes, we are not merged yet. I will try to find a volunteer for that.

Comment 32

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/5ce67a3a2bd0

Comment 33

[Steve England [:stevee]]

Is the 1.9.1 branch going to get this for beta 3?

Comment 34

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1842e495fc91