Closed Bug 240545 Opened 20 years ago Closed 16 years ago

Crash [@ js_MarkGCThing]

Categories

(Core :: JavaScript Engine, defect, P5)

1.7 Branch
x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: timeless, Assigned: timeless)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(2 files)

@see bug 228637, bug 237081

note that jsd is disabled for this run, unlike all other fun runs.
build is still pre 1.7a (i will fix that sometime soon, but first we're going 
to test the patch for bug 203278.

 	2f92783d()	
>	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x3d248e38, void * arg=0x0012e544)  Line 865 + 0x25	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x04d4cc20, void * arg=0x0012e5e4)  Line 919 + 0x3f	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x3d19da40, void * arg=0x0012e684)  Line 919 + 0x3f	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x3d1c6fc0, void * arg=0x0012e724)  Line 919 + 0x3f	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x3d1c6fb8, void * arg=0x0012e7c4)  Line 919 + 0x3f	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x3d1c7160, void * arg=0x0012e864)  Line 919 + 0x3f	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x02302910, void * 
thing=0x3d1c7168, void * arg=0x0012e8e0)  Line 919 + 0x3f	C
 	js3250.dll!gc_root_marker(JSDHashTable * table=0x009786c0, 
JSDHashEntryHdr * hdr=0x3d1c07fc, unsigned long num=204, void * 
arg=0x02302910)  Line 975 + 0x59	C
 	js3250.dll!JS_DHashTableEnumerate(JSDHashTable * table=0x009786c0, 
JSDHashOperator (JSDHashTable *, JSDHashEntryHdr *, unsigned long, void *)* 
etor=0x00acbef0, void * arg=0x02302910)  Line 618 + 0x19	C
 	js3250.dll!js_GC(JSContext * cx=0x02302910, unsigned int gcflags=0)  
Line 1188 + 0x15	C
 	js3250.dll!js_ForceGC(JSContext * cx=0x02302910, unsigned int 
gcflags=0)  Line 1000 + 0xd	C
 	js3250.dll!JS_GC(JSContext * cx=0x02302910)  Line 1684 + 0xb	C
 	js3250.dll!JS_MaybeGC(JSContext * cx=0x02302910)  Line 1703 + 0x9
	C
 	jsdom.dll!nsJSContext::ScriptEvaluated(int aTerminated=1)  Line 1686 + 
0xd	C++
...

From the top js_MarkGCThing:
-	obj->map->ops	0x3d247ee7 {newObjectMap=0x10101010 
destroyObjectMap=0xdbf7503c lookupProperty=0xdefc083c ...}	JSObjectOps *
	newObjectMap	0x10101010	JSObjectMap * (JSContext *, long, 
JSObjectOps *, JSClass *, JSObject *)*
	destroyObjectMap	0xdbf7503c	void (JSContext *, JSObjectMap 
*)*
	lookupProperty	0xdefc083c	int (JSContext *, JSObject *, long, 
JSObject * *, JSProperty * *)*
	defineProperty	0x00001001	int (JSContext *, JSObject *, long, 
long, int (JSContext *, JSObject *, long, long *)*, int (JSContext *, JSObject 
*, long, long *)*, unsigned int, JSProperty * *)*
	getProperty	0x0c000300	int (JSContext *, JSObject *, long, 
long *)*
	setProperty	0x08010a00	int (JSContext *, JSObject *, long, 
long *)*
	getAttributes	0x00000000	int (JSContext *, JSObject *, long, 
JSProperty *, unsigned int *)*
	setAttributes	0x45f24d00	int (JSContext *, JSObject *, long, 
JSProperty *, unsigned int *)*
	deleteProperty	0x2f926800	int (JSContext *, JSObject *, long, 
long *)*
	defaultValue	0x00000002	int (JSContext *, JSObject *, JSType, 
long *)*
	enumerate	0x0f000c00	int (JSContext *, JSObject *, 
JSIterateOp, long *, long *)*
	checkAccess	0x08000a00	int (JSContext *, JSObject *, long, 
JSAccessMode, long *, unsigned int *)*
	thisObject	0x2212a800	JSObject * (JSContext *, JSObject *)*
	dropProperty	0x82ec403d	void (JSContext *, JSObject *, 
JSProperty *)*
	call	0x2f927042	int (JSContext *, JSObject *, unsigned int, 
long *, long *)*
	construct	0x00000002	int (JSContext *, JSObject *, unsigned 
int, long *, long *)*
	xdrObject	0x03000300	int (JSXDRState *, JSObject * *)*
	hasInstance	0x08000a00	int (JSContext *, JSObject *, long, int 
*)*
	setProto	0x98f4d000	int (JSContext *, JSObject *, unsigned 
long, JSObject *)*
	setParent	0x23d85010	int (JSContext *, JSObject *, unsigned 
long, JSObject *)*
	mark	0x2f92783d	unsigned long (JSContext *, JSObject *, void *)*
	clear	0x00000002	void (JSContext *, JSObject *)*
	getRequiredSlot	0x06000300	long (JSContext *, JSObject *, unsigned 
long)*
	setRequiredSlot	0x08010a00	void (JSContext *, JSObject *, unsigned 
long, long)*
	obj->map->ops->mark	0x2f92783d	unsigned long (JSContext *, 
JSObject *, void *)*

Oddly, *only* newObjectMap is 0x10101010, all the others seem relatively 
reasonable.

There's an associative js array with ~26.5k entries of some flavor (url strings 
and two number fields). I don't know the details (I can get them...).

Of note (i suppose), mozilla is using 776mb of vm (460mb resident). wXP has 
1.2gb of vm available (before it needs to grow the swap file).
This is sort of low, mozilla on this box was once killed by msvcrt when it hit 
the 2gb limit. :)
Keywords: crash
Timeless, I'm crashing repeatly (and randomly) with trunk build with same
signature. Could you look at stacks, if I see same bug? TB3238187 or TB3153178.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
is this still an open problem with fix for bug 203278 checked in?

995 talkback reports against js_MarkGCThing, but none with a build dated after mid-september.  (and none of them are trunk)
*** Bug 286361 has been marked as a duplicate of this bug. ***
#6 topcrasher.
Keywords: topcrash
talkback TB16753835M

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ID:2006011112

same bug?

Stack Signature	 MarkGCThing 3796f114
Product ID	Firefox15
Build ID	2006011112
Trigger Time	2006-03-23 13:49:38.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0001d299)
URL visited	no URL
User Comments	another crash when sessionsaver was trying to recover my state :(
Since Last Crash	623689 sec
Total Uptime	3470411 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1146
Stack Trace 	
MarkGCThing  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1146]
js_MarkGCThing  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1446]
js_GC  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1801]
js_ForceGC  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsgc.c, line 1510]
nsAppStartup::Run  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 151]
main  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)
I was getting this crash under Linux when I had a link with target=_blank.  I was primarily experiencing the issues when clicking on a link when displaying an email in Horde webmail.  As of the current daily build, the links now open up successfully in a new tab in the same browser window.

I haven't changed any settings, only updated from Tuesday's (9 May) build to Thursday's (11 May) build.
QA Contact: pschwartau → general
I'm getting a hang on MacOSX 10.4.9 where FF gets stuck in an cascading set of calls to js_MarkGCThing (see attached trace).
I'm on: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

I have Gmail/Google Calendar/Hosted Gmail (apps for domain) open, with a few other tabs most of the time. the hang is fairly reproducible, happens every few days of continuous useage, then i have to force-quit FF.
I've also been getting this for a while (reappeared last week, though I've seen it before that), primarily on GMail.  Once I have had a buncha tabs open and used firefox for a while, I get spins when I open Gmail.  Activity monitor reports ~300 MB real memory and ~850MB virtual the last time this happened. I'm using a Mac Pro with 2 dual core CPUs and 6GB of ram.  I'm using firefox 2.0.0.6.

I had a few add-ons running; I've disabled them all now and will try to recreate the crash, but meanwhile enjoy three samples from my latest  spinlock: the first, second, and final (1min long, then force-quit) of 8 hangs within a 2-minute period.  Here's the top calls from the 1-min spin:
Total number in stack (recursive counted multiple, when >=5):
        994       js_MarkGCThing
        440       js_Mark
        327       xpc_MarkForValidWrapper(JSContext*, XPCWrappedNative*, void*)
        151       nsDOMClassInfo::MarkReachablePreservedWrappers(nsIDOMGCParticipant*, JSContext*, void*)
        149       nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&)
        132       nsQueryInterface::operator()(nsID const&, void**) const
        129       js_MarkScopeProperty
        123       XPCCallContext::XPCCallContext[in-charge](XPCContext::LangType, JSContext*, JSObject*, JSObject*, long, unsigned, long*, long*)
        112       __spin_lock
        111       PR_Lock
        98       JS_GetPrivate
        86       nsTreeColumnsSH::GetNamedItem(nsISupports*, nsAString_internal const&, nsISupports**)
        85       PR_Unlock
        85       nsCOMPtr_base::~nsCOMPtr_base [not-in-charge]()
I'm /very/ interested in getting this fixed, so please feel free to contact me with instructions on how to instrument the browser to catch the problem.
This should be WFM on the trunk, right? Can someone spot the bug whose patch fixed it there?

/be
Whiteboard: DUPEME
shouldn't this bug's Platform/OS be set to All/All? (cf. comments about crashes on both winXP and MacOsX)
(In reply to comment #11)
> This should be WFM on the trunk, right?

true for trunk - no js_MarkGCThing crashes for SM, FF, TB trunk on breakpad or talkback


> Can someone spot the bug whose patch fixed it there?

brendan, not sure what to dupe - there are at least 3 recently fixed bugs for MarkGCThing bug 352624, bug 361964, bug 361346 - also all fixed on branch. Is there an easy pick?  Or just close this WFM.


Note branches still crash - this is #35 crasher for version 2.0.0.6 - so anyone (philip, toli) crashing on 2.0.0.6 (perhaps earlier) and dont match up to existing bugs should file a new bug.  Example crashes and bugs  TB35259905, bug 317941
Version: Other Branch → 1.7 Branch
If the program spinlocks -- just hangs there -- is there a way to trigger the apple/talkback crash reporter?  It doesn't come up when I force quit.  (I'm sure this isn't the right forum and I will look harder for the answer -- but if someone can quickly point to it I'd be much obliged).  Once I can make crash reports I'll go about recreating the problem and file a new bug.
Haven't seen this issue come back ever since upgrading to Firefox 3.
Running this on MacOS 10.5.4 
I also had this go away immediately on upgrading to firefox 3, starting from the nightlies of about 2007-09-*.
timeless, does it make sense to close this yet?
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ js_MarkGCThing]
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: