Closed Bug 602225 Opened 14 years ago Closed 13 years ago

crash [@ js::gc::MarkObject ]

Categories

(Core :: JavaScript Engine, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, Whiteboard: [tbird topcrash][gs][fixed by bug 660778])

Crash Data

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
blocking2.0: --- → ?
Changing to all since there are a few Mac crashes in the mix as well.
OS: Windows XP → All
Hardware: x86 → All
blocking2.0: ? → betaN+
Are there any testcases to reproduce this? I'd be interested in seeing exactly what is causing MarkObject to crash.
> 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
This crash only seems to result in a consistent top stack frame. Every other frame seems to be different between most of the crashes.
blocking2.0: betaN+ → -
status2.0: --- → wanted
It is now #14 top crasher in 4.0b8 for the last week.
(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
We're probably going to want to bin these by:

- line number
- crash address

to make progress.
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
...
...
...
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
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?)
It is #15 top crasher in 4.0b12.
(In reply to comment #11)
> It is #15 top crasher in 4.0b12.

Add to keywords: common-issue+, topcrash
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.
This is #18 in the top crash list for 4.0 with over 19 million users. Can someone take a look at this.
Crash Signature: [@ js::gc::MarkObject ]
In 5.0 data, that signature is in the top 10 now.
#3 crash for thunderbird 5. 
bp-33958156-e594-47cc-b0ab-654a12110628 has an email address
Whiteboard: [tbird topcrash]
might this also be fixed by bug 662634?
no i isnt. have this bug too :<
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.
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.
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.
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.
(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
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!
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!
Andrew, the crashes in comment 25 look like infinite recursion in CC leading to stack overflow. Any idea what that might be about?
Bug 660778, fixed by billm in Fx6.

Tilman, you can try Beta 6 of Thunderbird, that may fix this problem.
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 )
(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.
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
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 660778
Resolution: --- → FIXED
Whiteboard: [tbird topcrash] → [tbird topcrash][gs][fixed by bug 660778]
You need to log in before you can comment on or make changes to this bug.