Closed Bug 519129 Opened 16 years ago Closed 16 years ago

Crash [@RecordTree] [@js_MonitorLoopEdge] [@js_Interpret] loading Zimbra webmail

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: vlad, Assigned: mrbkap)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Proposed fix
2.04 KB, patch
brendan
: review+
Details | Diff | Splinter Review
I'm getting a reproducible crash on session restore in today's nightly (27 Sept) on Win32. Here's the call stack: ChildEBP RetAddr 0020e6e4 6c569528 js3250!RecordTree(struct JSContext * cx = 0x088c9204, struct JSTraceMonitor * tm = 0x088c8604, struct VMFragment * f = 0x00000000, unsigned char * outer = 0x0020e9bc "???", unsigned long outerArgc = 0x8aef640, struct JSObject * globalObj = 0x0020edc8, unsigned long globalShape = 0, class Queue<unsigned short> * globalSlots = 0x00000000, unsigned long argc = 0)+0xf0 [js\src\jstracer.cpp @ 5371] 0020e770 6c577756 js3250!js_MonitorLoopEdge(struct JSContext * cx = 0x0491d7c5, unsigned int * inlineCallCount = 0x08c0c300)+0x618 [js\src\jstracer.cpp @ 6576] 0020e98c 6c592fbc js3250!js_Interpret(struct JSContext * cx = 0x088c8c00)+0x7c6 [js\src\jsops.cpp @ 905] 0020ea08 6c593901 js3250!js_Execute(struct JSContext * cx = 0x0020e7ac, struct JSObject * chain = 0x00000000, struct JSScript * script = 0x00000000, struct JSStackFrame * down = 0x07493ad0, unsigned int flags = 0, int * result = 0x00000000)+0x19c [js\src\jsinterp.cpp @ 1598] 0020ea7c 6c580029 js3250!obj_eval(struct JSContext * cx = 0x088c8c00, struct JSObject * obj = 0x08c0c240, unsigned int argc = 1, int * argv = 0x08aef6b4, int * rval = 0x0020eb04)+0x4b1 [js\src\jsobj.cpp @ 1504] 0020eb28 6c579a83 js3250!js_Invoke(struct JSContext * cx = 0x088c8c00, unsigned int argc = 1, int * vp = 0x08aef6ac, unsigned int flags = 2)+0x409 [js\src\jsinterp.cpp @ 1363] 0020ed7c 6c57fe8c js3250!js_Interpret(struct JSContext * cx = 0x088c8c00)+0x2af3 [js\src\jsops.cpp @ 2268] 0020ee18 6c58d283 js3250!js_Invoke(struct JSContext * cx = 0x088c8c00, unsigned int argc = 0, int * vp = 0x08aef208, unsigned int flags = 0)+0x26c [js\src\jsinterp.cpp @ 1371] 0020ee6c 6c578263 js3250!js_fun_apply(struct JSContext * cx = 0x088c8c00, unsigned int argc = 0, int * vp = 0x08aef1d0)+0x293 [js\src\jsfun.cpp @ 2038] 0020f0bc 6c57fe8c js3250!js_Interpret(struct JSContext * cx = 0x088c8c00)+0x12d3 [js\src\jsops.cpp @ 2244] 0020f158 6c58d283 js3250!js_Invoke(struct JSContext * cx = 0x088c8c00, unsigned int argc = 0, int * vp = 0x08aef14c, unsigned int flags = 0)+0x26c [js\src\jsinterp.cpp @ 1371] 0020f1ac 6c578263 js3250!js_fun_apply(struct JSContext * cx = 0x088c8c00, unsigned int argc = 0, int * vp = 0x08aef114)+0x293 [js\src\jsfun.cpp @ 2038] 0020f3f4 6c592fbc js3250!js_Interpret(struct JSContext * cx = 0x088c8c00)+0x12d3 [js\src\jsops.cpp @ 2244] 0020f470 6c59f5a1 js3250!js_Execute(struct JSContext * cx = 0x0020e7ac, struct JSObject * chain = <Memory access error>, struct JSScript * script = <Memory access error>, struct JSStackFrame * down = 0x07493ad0, unsigned int flags = <Memory access error>, int * result = <Memory access error>)+0x19c [js\src\jsinterp.cpp @ 1598] 0020f49c 62c5171f js3250!JS_EvaluateUCScriptForPrincipals(struct JSContext * cx = 0x088c8c00, struct JSObject * obj = 0x08c0c240, struct JSPrincipals * principals = 0x069268d4, unsigned short * chars = 0x1f0d56d0, unsigned int length = 0x17, char * filename = 0x1f14f9c8 "https://mail.mozilla.com/zimbra/js/Startup1_1_all.js.zgz?v=090707142524", unsigned int lineno = 0x5dc, int * rval = 0x00000000)+0x61 [js\src\jsapi.cpp @ 5057] 0020f510 62d4e47a xul!nsJSContext::EvaluateString(class nsAString_internal * aScript = 0x0020f5ec, void * aScopeObject = 0x08c0c240, class nsIPrincipal * aPrincipal = 0x069268d0, char * aURL = 0x1f14f9c8 "https://mail.mozilla.com/zimbra/js/Startup1_1_all.js.zgz?v=090707142524", unsigned int aLineNo = 0x5dc, unsigned int aVersion = 0, class nsAString_internal * aRetValue = 0x00000000, int * aIsUndefined = 0x0020f580)+0x136 [dom\base\nsjsenvironment.cpp @ 1682] 0020f5f8 62d77548 xul!nsGlobalWindow::RunTimeout(struct nsTimeout * aTimeout = 0x145f1b80)+0x4fa [dom\base\nsglobalwindow.cpp @ 7940] 0020f610 62c99dea xul!nsGlobalWindow::TimerCallback(class nsITimer * aTimer = 0x1f0bf640, void * aClosure = 0x145f1b80)+0x17 [dom\base\nsglobalwindow.cpp @ 8296] 0020f630 62c99fa0 xul!nsTimerImpl::Fire(void)+0x8a [xpcom\threads\nstimerimpl.cpp @ 427] 0020f638 62ccfd95 xul!nsTimerEvent::Run(void)+0x20 [xpcom\threads\nstimerimpl.cpp @ 521] And the crash location: eax=0020e9bc ebx=0070c028 ecx=00000004 edx=00000000 esi=0020e7ac edi=07493ad0 eip=6c59af30 esp=0020e6b8 ebp=088c8c00 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 js3250!RecordTree+0xf0: 6c59af30 0fb75220 movzx edx,word ptr [edx+20h] ds:002b:00000020=???? 6c59af0e 83782800 cmp dword ptr [eax+28h],0 6c59af12 7408 je js3250!RecordTree+0xdc (6c59af1c) 6c59af14 8b542418 mov edx,dword ptr [esp+18h] 6c59af18 8d4c1101 lea ecx,[ecx+edx+1] 6c59af1c 8b542414 mov edx,dword ptr [esp+14h] 6c59af20 85d2 test edx,edx 6c59af22 0f8528890200 jne js3250!RecordTree+0x28a10 (6c5c3850) 6c59af28 395028 cmp dword ptr [eax+28h],edx 6c59af2b 7416 je js3250!RecordTree+0x103 (6c59af43) 6c59af2d 8b501c mov edx,dword ptr [eax+1Ch] *** 6c59af30 0fb75220 movzx edx,word ptr [edx+20h] ds:002b:00000020=???? 6c59af34 8b4024 mov eax,dword ptr [eax+24h] 6c59af37 3bc2 cmp eax,edx 6c59af39 0f87ff020000 ja js3250!RecordTree+0x3fe (6c59b23e) 6c59af3f 8d4c1102 lea ecx,[ecx+edx+2] 6c59af43 8b4304 mov eax,dword ptr [ebx+4] 088c8c04 cx = 0x088c9204 088c8c08 tm = 0x088c8604 088c8c0c f = 0x00000000 088c8c10 outer = 0x0020e9bc "???" 088c8c14 outerArgc = 0x8aef640 088c8c18 globalObj = 0x0020edc8 088c8c1c globalShape = 0 088c8c20 globalSlots = 0x00000000 088c8c24 argc = 0 f and globalSlots being 0 seems bad here; not sure if those values are trustworthy, but everything else seems correct, and it matches the crash.
Seeing this on Mac as well, removing Zimbra from my session fixed it.
Keywords: crash
OS: Windows NT → All
Hardware: x86 → All
I'm reasonably sure that this worked fine with Friday's nightly, but not 100% positive. Not sure where to look to see an update log.
There was a Tracemonkey merge on Friday, conveniently enough: http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=e109f9a3b6ee I just hit this crash twice in a row.
Also, I can second Gavin's fix of removing Zimbra from your session to fix. That's probably the STR here.
Actually, looks like just loading Zimbra webmail crashes, sessionstore is not necessary.
Severity: normal → critical
Summary: Crash [@RecordTree] [@js_MonitorLoopEdge] [@js_Interpret] → Crash [@RecordTree] [@js_MonitorLoopEdge] [@js_Interpret] loading Zimbra webmail
Anyone up for bisecting a bit on the tracemonkey nightlies? Would probably help a good bit in getting a fix onto m-c quickly.
I can confirm Ted's comment 6 -- I crash immediately after logging in to Zimbra. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090928 Minefield/3.7a1pre http://crash-stats.mozilla.com/report/index/bp-2ed2c3f8-38b3-4723-9ca8-3cc5f2090928 http://crash-stats.mozilla.com/report/index/af9eb987-3187-4900-966f-5895e2090928
The first bad revision is: changeset: 33133:de72243414cd user: Blake Kaplan <mrbkap@gmail.com> date: Mon Aug 17 18:08:20 2009 -0700 summary: Bug 495325 - Follow ES about indirect eval being global eval. r=brendan/igor
I don't crash with a 9/21 or 9/25 tracemonkey nightly, but I do crash with a 9/26 nightly.
(In reply to comment #9) > The first bad revision is: > changeset: 33133:de72243414cd > user: Blake Kaplan <mrbkap@gmail.com> > date: Mon Aug 17 18:08:20 2009 -0700 > summary: Bug 495325 - Follow ES about indirect eval being global eval. > r=brendan/igor This actually matches my testing, because Blake didn't push this until 9/25 http://hg.mozilla.org/tracemonkey/pushloghtml?changeset=de72243414cd
Attached patch Proposed fix — — Splinter Review
We weren't pretending hard enough that we were at top level.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #403382 - Flags: review?(brendan)
Attachment #403382 - Flags: review?(brendan) → review+
Comment on attachment 403382 [details] [diff] [review] Proposed fix Comment the callerFrame initializing assignment about how we can't have a callerFrame (down in js_Execute) for global code, indirect eval code, or global eval code. /be
I pushed this to m-c because people were complaining about Zimbra: http://hg.mozilla.org/mozilla-central/rev/eec5815b761f still needs the comment Brendan asked for. Blake, please add that when you get a chance.
no tests?
Gary has one in another bug.
I have a follow-up question...
(In reply to comment #13) > Comment the callerFrame initializing assignment about how we can't have a > callerFrame (down in js_Execute) for global code, indirect eval code, or global > eval code. global direct eval code has a static depth of 1, so it gets a caller frame (this was unchanged in my patch).
I believe that http://hg.mozilla.org/mozilla-central/rev/207a8a1bdb38 answers the question shaver asks in comment 17.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
js/src/trace-test/tests/basic/bug519129.js v 1.9.3
Status: RESOLVED → VERIFIED
Did/should this land on mozilla-1.9.2? @js_Interpret is the topcrash on Firefox 3.6b1 by an order of magnitude.
Flags: blocking1.9.2?
Marking as blocking 1.9.2, mostly to get an answer to comment 22, but also because I think it should.
Flags: blocking1.9.2? → blocking1.9.2+
This isn't the @js_Interpret topcrash, and the bug didn't make it to 1.9.2 (fixed changeset was merged as a unit). No 1.9.2 action here.
Flags: blocking1.9.2+ → blocking1.9.2-
Crash Signature: [@RecordTree] [@js_MonitorLoopEdge] [@js_Interpret]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: