Closed Bug 487271 Opened 11 years ago Closed 11 years ago

Crash and missing google-maps background at [@ js_Invoke][@ JS_CallTracer]


(Core :: JavaScript Engine, defect, P1)






(Reporter: dholbert, Assigned: brendan)




(Keywords: crash, regression, verified1.9.1, Whiteboard: fixed-in-tracemonkey)

Crash Data


(3 files, 2 obsolete files)

 1. Visit URL
 2. Reload a bunch of times

 The page background should be a giant google maps canvas.  Also, it shouldn't crash.

 Page background is missing, and it crashes after a few reloads.  (Sometimes on the first reload, sometimes requires more, but so far I've been able to trigger a crash within ~15 sec of reloading)

Both issues (missing background and crash) appear to be new regressions in today's nightly.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090407 Minefield/3.6a1pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre


Looks likely to be a regression from sayrer's tracemonkey merge.
Related to bug 487238? (that bug mentions some crashes at js_invoke, as well as other spots, for a different URL)
Keywords: crash
FWIW, I hit this crash with jit.content disabled, too.
Attached patch Partial fix (obsolete) — Splinter Review
This fixes the first bug here, but there's more. brendan and I think that there's an eval that the analysis can't see through that is letting a function ('u' in this case) escape, making it a funarg.

brendan is going to write a patch to eagerly mark all sub-functions of a heavyweight (eval-using) function as a funarg.
Assignee: general → brendan
Embarrassing, considering I implemented the display for upvars, part un.

The eval thing was a case of me thinking the HEAVYWEIGHT flag poisoned the well, but it's not so. In a tree of functions T, with subtree S rooted at a function F that is a sibling of an eval callsite E, code eval'd by E cannot see F's kids, but it can certainly see F and help it escape. E can also see up the tree to all functions in enclosing functions. There can be more than one such F sibling, too, of course, and hoisting means E can facilitate the escape of any.

Flags: blocking1.9.1?
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b4
Also, amazing how much works if you assume dynamic and static link are equivalent. Shallow is better than deep.

Flags: in-testsuite?
Attached patch fix (obsolete) — Splinter Review
Attachment #371598 - Attachment is obsolete: true
Attachment #371623 - Flags: review?(mrbkap)
Blocks: 487312
I browsed google maps, ran SunSpider in-browser, used gmail...

Attachment #371623 - Attachment is obsolete: true
Attachment #371638 - Flags: review?(mrbkap)
Attachment #371623 - Flags: review?(mrbkap)
Attachment #371638 - Flags: review?(mrbkap) → review+
Duplicate of this bug: 487470
Bug 487445 might be a dupe
Severity: normal → critical
Fixed in tm:

I'll get it into m-c as soon as an incremental build is done with it and tested by folks looking for a fix. Thanks,

Severity: critical → normal
Whiteboard: fixed-in-tracemonkey
Testing with latest TM build, seems to fix the crashes...

Vista HP SP1
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090408 Minefield/3.6a1pre Firefox/3.0.7 ID:20090408134409 <- TM hourly build
Built tm with the patch, loaded Google maps, docs, mail, reader and calendar without crashing. Poked around each app for a few min without any noticeable issues.
Duplicate of this bug: 487294
Andreas, any thoughts on the red linux talos box:

Stack excerpt:

Crash reason:  SIGSEGV
Crash address: 0xb715eb04

Thread 0 (crashed)
 0!nanojit::StackFilter::read() [LIR.h:c78d2d3532c1 : 329 + 0x0]
    eip = 0xb715eb04   esp = 0xbfcc84f0   ebp = 0xbfcc8508   ebx = 0xb7170d34
    esi = 0xaec19060   edi = 0xbfcc8624   eax = 0xaec19060   ecx = 0x0000000b
    edx = 0xb0c19064   efl = 0x00210286
 1!nanojit::StackFilter::read() [LIR.cpp:c78d2d3532c1 : 1177 + 0xe]
    eip = 0xb715ea79   esp = 0xbfcc8510   ebp = 0xbfcc8538
 2!nanojit::DeadCodeFilter::read() [Assembler.cpp:c78d2d3532c1 : 81 + 0xb]
    eip = 0xb7159d14   esp = 0xbfcc8540   ebp = 0xbfcc8558
 3!nanojit::Assembler::gen(nanojit::LirFilter*, avmplus::List<unsigned char*, (avmplus::ListElementType)0>&) [Assembler.cpp:c78d2d3532c1 : 1075 + 0xb]
    eip = 0xb71592e9   esp = 0xbfcc8560   ebp = 0xbfcc85a8
 4!nanojit::Assembler::assemble(nanojit::Fragment*, avmplus::List<unsigned char*, (avmplus::ListElementType)0>&) [Assembler.cpp:c78d2d3532c1 : 849 + 0x6]
    eip = 0xb715941b   esp = 0xbfcc85b0   ebp = 0xbfcc8648
 5!nanojit::compile(nanojit::Assembler*, nanojit::Fragment*) [LIR.cpp:c78d2d3532c1 : 2147 + 0xd]
    eip = 0xb715c295   esp = 0xbfcc8650   ebp = 0xbfcc86a8
 6!TraceRecorder::compile(JSTraceMonitor*) [jstracer.cpp:c78d2d3532c1 : 2570 + 0x19]
    eip = 0xb7146473   esp = 0xbfcc86b0   ebp = 0xbfcc86d8
 7!TraceRecorder::closeLoop(JSTraceMonitor*, bool&) [jstracer.cpp:c78d2d3532c1 : 2706 + 0xc]
    eip = 0xb714feab   esp = 0xbfcc86e0   ebp = 0xbfcc8728
 8!TraceRecorder::checkTraceEnd(unsigned char*) [jstracer.cpp:c78d2d3532c1 : 3006 + 0x10]
    eip = 0xb714ffcc   esp = 0xbfcc8730   ebp = 0xbfcc8768
 9!TraceRecorder::ifop() [jstracer.cpp:c78d2d3532c1 : 5240 + 0xa]
    eip = 0xb7150cfd   esp = 0xbfcc8770   ebp = 0xbfcc87a8
10!TraceRecorder::monitorRecording(JSContext*, TraceRecorder*, JSOp) [jstracer.cpp:c78d2d3532c1 : 6468 + 0x8]
    eip = 0xb7155a57   esp = 0xbfcc87b0   ebp = 0xbfcc87d8
 . . .

Depends on: 487538
Duplicate of this bug: 487312
Closed: 11 years ago
Resolution: --- → FIXED
Flags: blocking1.9.1? → blocking1.9.1+
VERIFIED FIXED in today's nightly, using STR from comment 0.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090409 Minefield/3.6a1pre

Duplicate of this bug: 487238
This also fixed a crash in @JS_CallTracer (bp-c8739b46-9527-4375-b78c-0dd6c2090407) which I was able to see in bug 487238 and which was duped against this one. Updating summary.
OS: Linux → All
Hardware: x86 → All
Summary: Crash [@ js_Invoke ], and missing google-maps background, at → Crash and missing google-maps background at [@ js_Invoke][@ JS_CallTracer]
Target Milestone: mozilla1.9.1b4 → mozilla1.9.2a1
I'm not able to crash Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre ID:20090420031111. I assume it is fixed on 1.9.1 too.
Severity: normal → critical
Crash Signature: [@ js_Invoke] [@ JS_CallTracer]
You need to log in before you can comment on or make changes to this bug.