Last Comment Bug 602225 - crash [@ js::gc::MarkObject ]
: crash [@ js::gc::MarkObject ]
Status: RESOLVED FIXED
[tbird topcrash][gs][fixed by bug 660...
: crash, regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical with 1 vote (vote)
: ---
Assigned To: general
:
Mentors:
Depends on: 660778
Blocks: 613650
  Show dependency treegraph
 
Reported: 2010-10-06 09:03 PDT by Scoobidiver (away)
Modified: 2011-09-01 04:11 PDT (History)
20 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wanted


Attachments

Description Scoobidiver (away) 2010-10-06 09:03:40 PDT
Build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

It is a new crash signature that first appeared in 4.0b7pre/20100929 build.
It is #44 top crasher in 4.0b7pre for the last week.

Signature	js::gc::MarkObject
UUID	9efc178c-2f53-4ae3-9516-478632101006
Time 	2010-10-06 00:21:50.191596
Uptime	625
Last Crash	642 seconds (10.7 minutes) before submission
Install Age	1825 seconds (30.4 minutes) since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20101005041637
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Dodatek Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 15 model 1 stepping 3
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x220faffc
User Comments	
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 00f1
Processor Notes 	WARNING: No 'client_crash_date' could be determined from the Json file

Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	js::gc::MarkObject 	js/src/jsgcinlines.h:179
1 	mozjs.dll 	js::gc::MarkChildren 	js/src/jsgcinlines.h:191
2 	mozjs.dll 	js::gc::MarkObject 	js/src/jsgcinlines.h:179
3 	mozjs.dll 	js::gc::MarkChildren 	js/src/jsgcinlines.h:191
4 	mozjs.dll 	js::gc::MarkKind 	js/src/jsgcinlines.h:391
5 	mozjs.dll 	js_TraceObject 	js/src/jsobj.cpp:6202
6 	mozjs.dll 	js::gc::MarkChildren 	js/src/jsgcinlines.h:199
7 	mozjs.dll 	js::gc::MarkKind 	js/src/jsgcinlines.h:391
8 	mozjs.dll 	js_TraceObject 	js/src/jsobj.cpp:6202
9 	mozjs.dll 	js::gc::MarkChildren 	js/src/jsgcinlines.h:199
10 		@0x3fffff 	
11 	mozjs.dll 	js::gc::MarkKind 	js/src/jsgcinlines.h:391
12 	mozjs.dll 	js_TraceObject 	js/src/jsobj.cpp:6180

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c257bfb8cad0&tochange=a60414d076b5

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=js%3A%3Agc%3A%3AMarkObject&version=Firefox%3A4.0b7pre
Comment 1 Marcia Knous [:marcia - use ni] 2010-10-06 13:43:04 PDT
Changing to all since there are a few Mac crashes in the mix as well.
Comment 2 Alex Miller 2010-11-09 21:23:19 PST
Are there any testcases to reproduce this? I'd be interested in seeing exactly what is causing MarkObject to crash.
Comment 3 Scoobidiver (away) 2010-11-09 23:35:20 PST
> Are there any testcases to reproduce this?
No testcase. One comment in brazilian says "option".

It is now #27 top crasher in 4.0b8pre for the last week.
Here is a refresh link for reports:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=js%3A%3Agc%3A%3AMarkObject
Comment 4 Alex Miller 2010-11-10 07:44:00 PST
This crash only seems to result in a consistent top stack frame. Every other frame seems to be different between most of the crashes.
Comment 5 Scoobidiver (away) 2011-01-08 01:04:41 PST
It is now #14 top crasher in 4.0b8 for the last week.
Comment 6 chris hofmann 2011-01-21 14:13:08 PST
(In reply to comment #4)
> This crash only seems to result in a consistent top stack frame. Every other
> frame seems to be different between most of the crashes.

here is a sample of 20 reports on beta9

....Signature number: 16-js::gc::MarkObject
______ distribution of 20 different stacks, looking at top 10 frames
      6  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkKind
0|3|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      3  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkObject
0|3|mozjs.dll|js::gc::MarkChildren
0|4|mozjs.dll|js::gc::MarkKind
0|5|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      3  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|fun_trace
0|2|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js_TraceScript(JSTracer *,JSScript *)
0|3|mozjs.dll|fun_trace
0|4|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)
0|5|mozjs.dll|js::gc::MarkChildren
0|6|mozjs.dll|js::gc::MarkObject
0|7|mozjs.dll|fun_trace
0|8|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::Shape::trace(JSTracer *)
0|3|mozjs.dll|JSObject::trace(JSTracer *)
0|4|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)
0|5|mozjs.dll|js::gc::MarkChildren
0|6|mozjs.dll|js::gc::MarkObject
0|7|mozjs.dll|js::gc::MarkChildren
0|8|mozjs.dll|js::gc::MarkKind
0|9|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkObject
0|3|mozjs.dll|js::gc::MarkChildren
0|4|mozjs.dll|js::gc::MarkObject
0|5|mozjs.dll|js::gc::MarkChildren
0|6|mozjs.dll|js_TraceScript(JSTracer *,JSScript *)
0|7|mozjs.dll|fun_trace
0|8|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)
0|9|mozjs.dll|js::gc::MarkChildren

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkObject
0|3|mozjs.dll|js::gc::MarkChildren
0|4|mozjs.dll|js::gc::MarkObject
0|5|mozjs.dll|js::gc::MarkChildren
0|6|mozjs.dll|js::gc::MarkKind
0|7|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkObject
0|3|mozjs.dll|js::gc::MarkChildren
0|4|mozjs.dll|js::gc::MarkObject
0|5|mozjs.dll|js::gc::MarkChildren
0|6|mozjs.dll|js::gc::MarkKind
0|7|mozjs.dll|JS_CallTracer
0|8|xul.dll|TraceJSObject
0|9|xul.dll|TraceJSHolder

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkObject
0|3|mozjs.dll|fun_trace
0|4|mozjs.dll|js_TraceObject(JSTracer *,JSObject *)

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkKind
0|3|mozjs.dll|gc_root_traversal
0|4|mozjs.dll|js::MarkRuntime(JSTracer *)
0|5|mozjs.dll|MarkAndSweep
0|6|mozjs.dll|GCUntilDone
0|7|mozjs.dll|JS_GC
0|8|xul.dll|nsXPConnect::Collect()
0|9|xul.dll|nsXPConnect::GarbageCollect()

      1  stacks like
0|0|mozjs.dll|js::gc::MarkObject
0|1|mozjs.dll|js::gc::MarkChildren
0|2|mozjs.dll|js::gc::MarkKind
0|3|mozjs.dll|array_trace

more places where js::gc::MarkObject is on the stack, but deeper can be found by searching http://people.mozilla.org/crash_stacks/stack-summary-4.0b9.txt
Comment 7 Mike Shaver (:shaver -- probably not reading bugmail closely) 2011-01-21 16:10:02 PST
We're probably going to want to bin these by:

- line number
- crash address

to make progress.
Comment 8 chris hofmann 2011-01-21 16:29:28 PST
That kind of list looks like a pretty long tail. for the 206 reports we got yesterday here is what the sample of top combinations are:

count  sig  crash address  line_no.

  39 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032

like:
http://crash-stats.mozilla.com/report/index/ff61f0dd-f78c-4da9-91b4-462462110120

   5 js::gc::MarkObject 0xfb000          hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032

like:
http://crash-stats.mozilla.com/report/index/ffa8b031-3469-4920-a4cf-1390f2110120

   4 js::gc::MarkObject 0x200faffc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032

like:
http://crash-stats.mozilla.com/report/index/c77815c2-b10f-4612-a96f-253422110120

   3 js::gc::MarkObject 0xffffffffffffeffc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:297086a0fb61
   3 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:297086a0fb61
   2 js::gc::MarkObject 0x7fc000         hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   2 js::gc::MarkObject 0x6fd694         hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   2 js::gc::MarkObject 0x677fc5b0       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   2 js::gc::MarkObject 0x542574         hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   2 js::gc::MarkObject 0x240faffc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   2 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:d78f9cb65e91
   2 js::gc::MarkObject 0x108fb848       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   1 js::gc::MarkObject 0xffffffffffffeffc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   1 js::gc::MarkObject 0xffffffffffffef44       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   1 js::gc::MarkObject 0xffffffffffffec30       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   1 js::gc::MarkObject 0xffffffffff2fec94       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:d78f9cb65e91
...
...
...
Comment 9 chris hofmann 2011-01-21 16:40:24 PST
we can also bundle that same crash address across signatures for a list that looks like

  39 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   3 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:297086a0fb61
   3 js::Shape::trace(JSTracer*) 0x1fffebfc      hg:hg.mozilla.org/mozilla-central:js/src/jsscope.cpp:859a97109032
   2 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:d78f9cb65e91
   2 js::gc::MarkKind 0x1fffebfc         hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:d78f9cb65e91
   1 mozjs.dll@0x5e323 0x1fffebfc        
   1 js_TraceScript(JSTracer*, JSScript*) 0x1fffebfc     hg:hg.mozilla.org/mozilla-central:js/src/jsscript.cpp:859a97109032
   1 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:eb105fe0e41c
   1 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:e807269acaa3
   1 js::gc::MarkObject 0x1fffebfc       hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:3d4620449437
   1 js::gc::MarkKind 0x1fffebfc         hg:hg.mozilla.org/mozilla-central:js/src/jsgcinlines.h:859a97109032
   1 js::Shape::trace(JSTracer*) 0x1fffebfc      hg:hg.mozilla.org/mozilla-central:js/src/jsscope.cpp:d78f9cb65e91
   1 IsAboutToBeFinalized(JSContext*, void*) 0x1fffebfc          hg:hg.mozilla.org/mozilla-central:js/src/jsgc.cpp:859a97109032
Comment 10 Jim Blandy :jimb 2011-02-23 14:55:36 PST
It seems to me that any stray write bug that tends to hit heap objects will generate stacks like this, since the GC is the first thing that will notice the corruption of an object that isn't actively being used.

More valuable would be things like 1) what changesets' presence affected the rate of appearance; 2) what value had been written into the object (perhaps?)
Comment 11 Scoobidiver (away) 2011-03-03 06:31:42 PST
It is #15 top crasher in 4.0b12.
Comment 12 shawn.sumin 2011-03-10 19:50:27 PST
(In reply to comment #11)
> It is #15 top crasher in 4.0b12.

Add to keywords: common-issue+, topcrash
Comment 13 Scoobidiver (away) 2011-03-11 00:16:45 PST
In reply to comment 12
> Add to keywords: common-issue+, topcrash
According to me, common-issue+ is for no-crash bugs.
I though topcrash was reserved for the top-10 crashers (overall, Mac or Linux only, with combined signatures).
Moreover, when it is no longer a topcrasher, it is not removed. Indeed, there is currently 628 bugs with topcrash as keyword. A little clean-up would be necessary if you want this keyword has a meaning.
Comment 14 Sheila Mooney 2011-03-31 11:15:02 PDT
This is #18 in the top crash list for 4.0 with over 19 million users. Can someone take a look at this.
Comment 15 Robert Kaiser (not working on stability any more) 2011-06-23 12:47:39 PDT
In 5.0 data, that signature is in the top 10 now.
Comment 16 Jim Blandy :jimb 2011-06-27 09:45:44 PDT
See comment 10.
Comment 17 Wayne Mery (:wsmwk, NI for questions) 2011-06-29 05:46:21 PDT
#3 crash for thunderbird 5. 
bp-33958156-e594-47cc-b0ab-654a12110628 has an email address
Comment 18 Wayne Mery (:wsmwk, NI for questions) 2011-07-13 07:22:48 PDT
might this also be fixed by bug 662634?
Comment 19 fastb 2011-07-24 21:53:52 PDT
no i isnt. have this bug too :<
Comment 20 Aaron 2011-08-04 06:06:50 PDT
I'm having this crash (and a few other GC/JS-related ones) 10 times a day or so with 5.0.1. Somtimes several times within a few minutes (it crashed 3 times on me while writing this comment), sometimes not for hours. And it only started after i moved to a different PC (winXP 32bit -> win7 64bit).

I'm suspecting spurious hardware failures (defect memory, failing IO?) but it's mostly firefox that's crashing and I haven't had time for testing yet. Not to mention that i'm running a big virtual machine on the system and would expect that one to crash too, but it hasn't so far.
Comment 21 Bill McCloskey (:billm) 2011-08-04 11:47:37 PDT
Aaron, if you're willing to make the effort, you can download a recent debug build of Firefox here:
  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-08-04-03-07-32-mozilla-central/firefox-8.0a1.en-US.win32.zip

If you can make it crash, then we can follow these instructions and get a core dump:
  https://developer.mozilla.org/en/Remote_debugging

Then I can look at it on my end and maybe figure out how to fix it.
Comment 22 Aaron 2011-08-05 07:42:08 PDT
Ok, I tried with the debug build and didn't get it quite right (not much experience with windbg), but I saw something interesting:

The debugger stopped in an access violation in the cycle collector (I took a minidump of that) but when I resumed firefox it was still working (I was able to switch tabs). A few seconds later the actual crash happend but I couldn't get a minidump of that.
Comment 23 Aaron 2011-08-05 07:42:42 PDT
Ok, I tried with the debug build and didn't get it quite right (not much experience with windbg), but I saw something interesting:

The debugger stopped in an access violation in the cycle collector (I took a minidump of that) but when I resumed firefox it was still working (I was able to switch tabs). A few seconds later the actual crash happend but I couldn't get a minidump of that.
Comment 24 Wayne Mery (:wsmwk, NI for questions) 2011-08-10 05:31:12 PDT
(In reply to fastb from comment #19)
> no i isnt. have this bug too :<

fastb, are you running version 6 or higher where you see this crash, and can you post crash ID?


I'm far from 100% certain, but thinking this is fixed via Bug 660778/662634. Although there are some rare examples in v6 (3 to be exact) like bp-11f01854-a12a-42f9-9aab-4a8842110804
Comment 25 Tilman 2011-08-12 08:55:52 PDT
I've had this crash on two different PCs with thunderbird 5, there are probably over 30 crashes just by me. Current examples:
bp-6b495ad3-0e31-4627-ab6b-988672110812
bp-58e18b7f-6c12-4af6-ad25-f2fb82110812
On both W7 PCs, I installed Thunderbird 5 from scratch.
It must have something to do with IMAP communication, because it does not happen when offline (-P option then offline). It always happens when TB starts to communicate with the server, sometimes already when it checks what the capabilities of the IMAP server are.
I use IMAP, port 143, STARTTLS, password encrypted. Junk filter enabled. I get lots of mails, mostly spam and google news alerts.
The crash does not always happen immediately, but always when connecting to the server. Which suggests that it deals with uninitialized values or similar hard to reproduce stuff.
Work around is to set up a new profile with -P. On my new netbook, I already had to do this twice in a single day so I'm pretty P'ed off!

I'm not willing to run a debug version, because of security - sorry. However I can answer more questions about my configuration.

The least you should do is to make a code review of the IMAP communication module(s), maybe look what changed between 3 and 5. And increase the post mortem handling, please!
Comment 26 Tilman 2011-08-12 09:04:42 PDT
I switched to the f*cked profile to create crashes and write the report above. And after writing this, and switching back to the "good" profile, now that one crashes as well. Aaaargh!
Comment 27 David Mandelin [:dmandelin] 2011-08-12 11:13:13 PDT
Andrew, the crashes in comment 25 look like infinite recursion in CC leading to stack overflow. Any idea what that might be about?
Comment 28 Andrew McCreight [:mccr8] 2011-08-12 11:17:43 PDT
Bug 660778, fixed by billm in Fx6.

Tilman, you can try Beta 6 of Thunderbird, that may fix this problem.
Comment 29 Tilman 2011-08-12 13:10:14 PDT
Thanks Andrew and billm. Both profiles on this PC did not crash, same for all three profiles on the netbook. If I don't follow up until wednesday, then it means that this one works. However Bill's comment #3 on Bug 660778 sounds like he fixed a follow-up symptom... hmmmm... Just my "spectator" comment. I've done such symptom fixes myself in other peoples sources, but its only a temporary solution. I could be wrong, so no offense meant here, and thanks anyway. Good luck!
(I downloaded the beta from http://www.mozilla.org/en-US/thunderbird/all-beta.html )
Comment 30 Aaron 2011-09-01 02:51:21 PDT
(In reply to Aaron from comment #20)
My case turns out to be some sort of odd hardware instability. When I have a background process running eating up all idle CPU time on at least one core it's working without crashes. No idea what's causing this, but at least it's not a bug in FF.
Comment 31 Wayne Mery (:wsmwk, NI for questions) 2011-09-01 04:11:22 PDT
yay! indeed TB6 is pretty clean.[1] Tilman's findngs are consistent with TB6 topcrash list, where the signature has dropped to #219. And users in getsatisfaction http://getsatisfaction.com/mozilla_messaging/tags/js::gc::MarkObject over the past month have consistently found their problem to be gone when using version 6. Further, zero crashes in the past month for builds newer than version 6 [2].

#204 in Firefox 6 topcrash. And not in top 300 for FF7. So I think we can close this bug, and open new one for any remaining issues. Thanks Andrew for the patch in bug 660778, landed 2011-07-13 

[1] The crashes still seen in v6 may be slightly different, based on spot checking:
bp-3b07de28-64d3-4106-b738-030f92110829
0	libxul.so	js::gc::MarkObject	js/src/jsgc.h:349
1	libxul.so	fun_trace	js/src/jsfun.cpp:1969
2	libxul.so	js::GCMarker::drainMarkStack	js/src/jsgcmark.cpp:557 
bp-981b4e6c-0281-41f3-8a24-3d8212110831
0	mozjs.dll	js::gc::MarkObject	js/src/jsgcmark.cpp:120
1	mozjs.dll	js::gc::MarkChildren	js/src/jsgcmark.cpp:651
2	mozjs.dll	JS_TraceChildren	js/src/jsgcmark.cpp:753
3	xul.dll	xpc_UnmarkGrayObjectRecursive	js/src/xpconnect/src/nsXPConnect.cpp:648 


[2] builds newer than version 6 https://crash-stats.mozilla.com/query/query?product=Thunderbird&version=Thunderbird%3A9.0a1&version=Thunderbird%3A8.0a2&version=Thunderbird%3A8.0a1&version=Thunderbird%3A7.0a2&version=Thunderbird%3A7.0&range_value=4&range_unit=weeks&date=09%2F01%2F2011+03%3A50%3A16&query_search=signature&query_type=contains&query=js%3A%3Agc%3A%3AMarkObject&reason=&build_id=&process_type=any&hang_type=any&do_query=1

Note You need to log in before you can comment on or make changes to this bug.