Closed Bug 240545 Opened 21 years ago Closed 16 years ago

Crash [@ js_MarkGCThing]

Categories

(Core :: JavaScript Engine, defect, P5)

Product:
Core
Component:
JavaScript Engine
Version:
1.7 Branch
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: timeless, Assigned: timeless)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(2 files)

Thread dump for hung Firefox in js_markGCThing on MacOSX
11.31 KB, text/plain
Details
GZip'ed Text file giving three samples from a 2-minute (terminal) hang during load of gmail (mostly in js_markGCThing)
105.36 KB, application/octet-stream
Details
@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: