Closed
Bug 420848
Opened 16 years ago
Closed 16 years ago
crash [@ JS_BeginRequest]
Categories
(Thunderbird :: General, defect)
Thunderbird
General
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 422178
People
(Reporter: wsmwk, Unassigned)
Details
(Keywords: crash, topcrash)
Crash Data
crash [@ JS_BeginRequest] topcrash for thunderbird. TB crashes began with build 2008013003 (but there may be FF crashes that predate this - I didn't check the FF stacks). appears to be OS=ALL. No idea what this is about - it would sure help if crash-stats listed comments in it's reports table view. Found one with comment but might not be same issue (different stack) "server offline, trying to read sent doc with large attachment", bp-0b1f54b0-d615-11dc-af9d-001a4bd46e84 bug 398045 last addressed a JS_BeginRequest issue not much useful in stack, perhaps because of Bug 420759 – only public symbols for spidermonkey in breakpad since 12/14 BP-2cb216f8-d0d6-11dc-96fd-001a4bd43e5c Signature JS_BeginRequest UUID 2cb216f8-d0d6-11dc-96fd-001a4bd43e5c Time 2008-02-01 06:53:48-08:00 Uptime 0 Product Thunderbird Version 3.0a1pre Build ID 2008013003 OS Mac OS X OS Version 10.5.1 9B18 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 6 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0xc20d64 Frame Signature Source 0 JS_BeginRequest mozilla/js/src/jsapi.c:842 1 JS_ResumeRequest mozilla/js/src/jsapi.c:965 2 thunderbird-bin@0xb6fa3 3 thunderbird-bin@0x529cf5 ... 35 thunderbird-bin@0x14b317 36 nsThread::ProcessNextEvent(int, int*) mozilla/xpcom/threads/nsThread.cpp:510 37 NS_ProcessNextEvent_P(nsIThread*, int) nsThreadUtils.cpp:227 38 nsThread::ThreadFunc(void*) mozilla/xpcom/threads/nsThread.cpp:254 39 _pt_root mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 40 libSystem.B.dylib@0x31074 41 libSystem.B.dylib@0x30f31
nope, that bug's windows. and you really do have symbols for JS_BeginRequest/JS_ResumeRequest. fwiw, cx is probably null (note that JS_ResumeRequest doesn't use cx, so crashing in JS_BeginRequest for a null cx is reasonable). why thunderbird-bin doesn't have symbols is also a good question. any idea when that broke? :)
Comment 2•16 years ago
|
||
thunderbird-bin has been broken on and off. Phil: I thought it un-broke at some point? Did it break again? I haven't been able to reproduce the breakage on my own machine, so I haven't made any progress there.
Comment 3•16 years ago
|
||
bug 411171 was what I was thinking of. The symbols on stage from yesterday's build look reasonable, looks like Phil inadvertently fixed it about the beginning of February, the build from comment 0 is from January.
Comment 4•16 years ago
|
||
(In reply to comment #0) > No idea what this is about - it would sure help if crash-stats listed comments > in it's reports table view. Found one with comment but might not be same issue It does right now. I'm very excited about this new feature. It helps us a lot! Confirming based on crash id.
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
Product: Thunderbird → Core
QA Contact: general → general
Back to TB:General for more investigation, since if JS_ResumeRequest is being called with a bogus cx, SpiderMonkey isn't going to be able to save the caller. (Not sure that a NULL cx would lead to the crash address shown in those reports, but it could be a stale one or some other violation of XPConnect or SpiderMonkey invariants.)
Assignee: general → nobody
Component: JavaScript Engine → General
Product: Core → Thunderbird
QA Contact: general → general
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Updated•16 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ JS_BeginRequest]
You need to log in
before you can comment on or make changes to this bug.
Description
•