Closed Bug 420848 Opened 16 years ago Closed 16 years ago

crash [@ JS_BeginRequest]

Categories

(Thunderbird :: General, defect)

defect
Not set
critical

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? :)
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.
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.
(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
Status: RESOLVED → VERIFIED
Crash Signature: [@ JS_BeginRequest]
You need to log in before you can comment on or make changes to this bug.