User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090817 Namoroka/3.6a2pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090817 Namoroka/3.6a2pre (.NET CLR 3.5.30729) Opening one of my 100+ tab sessions and browsing for awhile, is resulting in one of the crashes listed at random. Testing from the earliest to the latest, i went through my entire list of extensions and disabled each one till i had none loaded, I also had done the same for plugins earlier. I ran firefox in safe mode with plugins enabled and it was more stable, Though since safemode disables JIT, I'm now thinking it is probably a bug there. bp-a56ff25f-294e-4b21-8de4-0b0352090817 18/08/2009 8:14 AM bp-e763caa1-29c2-4dd7-9c0e-5da302090817 18/08/2009 7:10 AM bp-9b98761b-2b9f-4a52-a598-cbbd52090816 17/08/2009 4:39 PM bp-e2e2796c-baf0-4384-be10-9d97d2090816 17/08/2009 12:24 PM bp-89143523-4a2a-48fd-864d-170832090816 17/08/2009 10:35 AM bp-9cf79bdb-3b9a-48e1-a21c-a773b2090816 17/08/2009 9:10 AM bp-848466a9-0179-4614-a42e-ae4692090816 17/08/2009 8:10 AM bp-0b9c491f-8ce6-4418-a5f4-1c1c42090816 17/08/2009 7:21 AM bp-f0a3025c-1765-465b-8414-76a332090816 17/08/2009 6:24 AM bp-e8210bdf-4392-4797-a21b-e2ddb2090816 17/08/2009 3:34 AM bp-7a768ee3-96b6-413c-88cc-bca152090815 16/08/2009 1:38 PM bp-0b429b46-e435-4b07-b3e0-0da4b2090815 16/08/2009 6:50 AM bp-9c5518c1-6167-4fc4-9d77-bd3652090815 16/08/2009 6:17 AM bp-3e045c5d-f7c4-41ca-ae1e-b7e852090815 16/08/2009 4:24 AM bp-f6ed6e5f-94b4-45d3-81e9-1d9db2090815 16/08/2009 2:27 AM bp-76892d50-048b-49c7-b021-6a14b2090815 16/08/2009 12:41 AM bp-92e9ed5f-5b0f-40c5-b358-4448c2090814 15/08/2009 3:12 AM bp-6ee15718-3cca-4ecc-b3d6-8982b2090812 13/08/2009 10:11 AM Reproducible: Always Steps to Reproduce: 1. Browse sites which have intense amounts of Js like Facebook, dailymotion, youtube. (I can provide a Session file if needs be) 2. Open multiple instances of the sites in seperate tabs, change pages, watch vids. Actual Results: Firefox will randomly crash at some point in the Js core. Expected Results: Firefox runs perfectly fine, like 3.5.2 does. Theme : Default Extensions : None Plugins : Disabled Safemode : Was stable for the time i used it. Disabling JIT in normal mode, also improved stability. http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1bf16951d1be http://crash-stats.mozilla.com/report/index/bp-a56ff25f-294e-4b21-8de4-0b0352090817 http://crash-stats.mozilla.com/report/index/bp-e763caa1-29c2-4dd7-9c0e-5da302090817 http://crash-stats.mozilla.com/report/index/bp-9b98761b-2b9f-4a52-a598-cbbd52090816 http://crash-stats.mozilla.com/report/index/bp-e2e2796c-baf0-4384-be10-9d97d2090816 http://crash-stats.mozilla.com/report/index/bp-89143523-4a2a-48fd-864d-170832090816 http://crash-stats.mozilla.com/report/index/bp-9cf79bdb-3b9a-48e1-a21c-a773b2090816 http://crash-stats.mozilla.com/report/index/bp-848466a9-0179-4614-a42e-ae4692090816 http://crash-stats.mozilla.com/report/index/bp-0b9c491f-8ce6-4418-a5f4-1c1c42090816 http://crash-stats.mozilla.com/report/index/bp-f0a3025c-1765-465b-8414-76a332090816 http://crash-stats.mozilla.com/report/index/bp-e8210bdf-4392-4797-a21b-e2ddb2090816 http://crash-stats.mozilla.com/report/index/bp-7a768ee3-96b6-413c-88cc-bca152090815 http://crash-stats.mozilla.com/report/index/bp-0b429b46-e435-4b07-b3e0-0da4b2090815 http://crash-stats.mozilla.com/report/index/bp-9c5518c1-6167-4fc4-9d77-bd3652090815 http://crash-stats.mozilla.com/report/index/bp-3e045c5d-f7c4-41ca-ae1e-b7e852090815 http://crash-stats.mozilla.com/report/index/bp-f6ed6e5f-94b4-45d3-81e9-1d9db2090815 http://crash-stats.mozilla.com/report/index/bp-76892d50-048b-49c7-b021-6a14b2090815 http://crash-stats.mozilla.com/report/index/bp-92e9ed5f-5b0f-40c5-b358-4448c2090814 http://crash-stats.mozilla.com/report/index/bp-6ee15718-3cca-4ecc-b3d6-8982b2090812

Severely minimized my session and..... http://crash-stats.mozilla.com/report/index/bp-274728dc-b4ba-4efe-bda2-68ee72090819

Also occurs in the Trunk.

Danial: this is great investigation, thank you! Would it be possible for you to get set up with WinDbg so that we can get some more information out of the crashes (perhaps including a minidump if you're willing to share that with us!) and you can work with some of the JS developers to get to the bottom of them? https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg has information on setting up WinDbg. Copying sayrer here to help find owners for the resulting sub-bugs, and graydon because he has experience getting minidumps and working through windbg. Thanks again for your help and perseverence!

Is it normal for a bunch of unhandled exceptions to display in the logger while using windbg? they don't seem to be effecting usage

80000001 guard page is an exception that flash uses (it's scary, but as long as we know it's flash, we'll live). 000006ba appears to be an rpc error (server missing?), that kind of error would likely repeat itself. An interesting question is what's performing rpc (as gecko doesn't typically). Handled exceptions aren't entirely unexpected, however strange exceptions can mean foreign code has invaded the process. Stopping for the exception to find out which module invaded can be worthwhile at times. sxe -c "kp" 000006ba should probably work (untested)

Ok, will check. Nothing has changed for me since 3.5.2 though, and it works perfectly, for days on end with no crashes, even if i standby, or hibernate.

7c90e485 e8e6c40100 call ntdll!RtlDispatchException (7c92a970) 0:011> p (8e0.1268): Unknown exception - code 000006ba (first chance) not that i know much, but i would believe it has to do with my realtek lan drivers?

ModLoad: 76f20000 76f47000 C:\WINDOWS\system32\DNSAPI.dll (8e0.1730): Unknown exception - code 000006ba (first chance) yeah, its network related. probably because i have the dns service disabled even. it also occurs in other apps so it shouldn't be a problem :)

I just crashed bp-4b04608f-457f-4586-9984-edd012090825 I was away from keyboard. 3.7a1pre 20090817050221 I rarely crash. But I had google maps up, which I don't usually have open. http://maps.google.com/maps?f=q&hl=en&geocode=&time=&date=&ttype=&q=40.80383,-75.45033&ie=UTF8&ll=40.80383,-75.45033&spn=0.350422,0.478592&z=11&iwloc=addr&om=1

Yep, i've had googlemaps do it to me a couple of times with just it open, i was using large sessions to get it to crash quicker though...

Firefox wouldn't start at all using sxe -c "kp" 000006ba

it looks like the 06ba errors can be disregarded like i said, it appears to be in mwsock and since all my network operators perfectly fine otherwise. note, its not tha only app that reports the issue... many others do as well (XP SP3 issue?) Shall i create a new crash log with the 06ba errors ignored/disabled?

Well this is after disabling 000006ba

I've started to seen this, or perhaps some variant of this, around once a day.

It doesn't appear to be related to the content, the crashes occur mainly when accessing parts of the interface, I've had it crash by opening the right click menu. Crash by hovering over the button bar. Crash by minimising the browser. Sites that manipulate the ability to bring up browser UI elements can also effect it.. like with google maps.

Not blocking. If you get a way to reproduce, please let us know and re-nom.

its not something that can just be reproduced, it occurs randomly during any period of general browsing. And only in 3.6/3.7, 3.5 is unaffected and works fine. However, I have noticed that leading up to a crash, the session.js file suddenly starts to bork, preventing me from saving the session, and on occasion preventing the on crash backup from working. Might even be something that can only be reproduced on XP.

bz saw something (on linux i think) that sounded like comment 19.

I was on Mac. The sessionstore file was sorta-weird in that it thought all the windows were closed, I think... Kinda hard to read that gunk.

Yeah, i think thats part of it too. had it happen here.

FWIW I ended up here after crashing like this (http://crash-stats.mozilla.com/report/index/89799b7e-0662-45dd-b20b-c326f2090918) on Vista with the nightly branch. Not doing anything special, about 15 tabs in two windows. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090918 Namoroka/3.6a2pre ID:20090918053309

The last crash (comment 23) is on line 1458 of jsops.cpp in JSOP_GETPROP (http://hg.mozilla.org/releases/mozilla-1.9.2/file/145e56834616/js/src/jsops.cpp#l1458): 1458 rval = LOCKED_OBJ_GET_SLOT(obj2, slot); I think many of the others are from another line in the same op: 1475 if (entry 1476 ? !js_GetPropertyHelper(cx, obj, id, true, &rval) 1477 : !obj->getProperty(cx, id, &rval)) { If you look at that area in 'annotate', you will mostly see that it was moved by sully to jsops.cpp. It's 'possible' that is the cause of the problem, but it seems very unlikely as his move so far just moved the cases to a new file. Since then, the only change to this case was this (http://hg.mozilla.org/releases/mozilla-1.9.2/diff/4c1b61b0138d/js/src/jsops.cpp, by jorendorff): 1.129 @@ -1476,7 +1474,7 @@ 1.130 id = ATOM_TO_JSID(atom); 1.131 if (entry 1.132 ? !js_GetPropertyHelper(cx, obj, id, true, &rval) 1.133 - : !OBJ_GET_PROPERTY(cx, obj, id, &rval)) { 1.134 + : !obj->getProperty(cx, id, &rval)) { 1.135 goto error; 1.136 } 1.137 } while (0); Again, presumably a no-effect change that is very unlikely to be causing a problem. Before Sully's changes the file is this: http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/16ed299a2012/js/src/jsinterp.cpp#l4416. Most of the last changes are pretty old, so that doesn't look very promising either. But I thought maybe people that have worked on this code might have a guess as to the problem (assuming it even is in the code for this case).

bp-e97bda9e-4e1a-47da-9788-5718c2090920 bp-4b04608f-457f-4586-9984-edd012090825 in both cases my PC was "unattended", and google calendar web page would have been one of the tabs

is anyone seeing this on non-windows platforms?

Boris had the weird sessions.js issue on Mac

xref Bug 517599 - Crash [@ js_LookupPropertyWithFlags]

(In reply to comment #26) > is anyone seeing this on non-windows platforms? On OSX at least (In reply to comment #27) > Boris had the weird sessions.js issue on Mac I just managed to catch the crash in gdb. Current cx->fp>script->filename is nsSessionStore.js and lineno 1539

My build is a bit old http://hg.mozilla.org/mozilla-central/rev/36a582d5c645

Got the crash again with a m-c build from yesterday. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 js_Interpret (cx=0x89e200) at jsops.cpp:1507 1507 rval = LOCKED_OBJ_GET_SLOT(obj2, slot); (gdb) bt #0 js_Interpret (cx=0x89e200) at jsops.cpp:1507 #1 0x00203080 in js_Invoke (cx=0x89e200, argc=3, vp=0x26e903e4, flags=0) at jsinterp.cpp:1371 #2 0x001b6c91 in array_extra (cx=0x89e200, mode=FOREACH, argc=<value temporarily unavailable, due to optimizations>, vp=0x26e903c0) at /Users/smaug/mozilla/hg/mozilla/js/src/jsarray.cpp:3193 #3 0x001fcf76 in js_Interpret (cx=0x89e200) at jsops.cpp:2235 #4 0x00203080 in js_Invoke (cx=0x89e200, argc=3, vp=0x26e903ac, flags=0) at jsinterp.cpp:1371 #5 0x001b6c91 in array_extra (cx=0x89e200, mode=FOREACH, argc=<value temporarily unavailable, due to optimizations>, vp=0x20258cf4) at /Users/smaug/mozilla/hg/mozilla/js/src/jsarray.cpp:3193 #6 0x001fcf76 in js_Interpret (cx=0x89e200) at jsops.cpp:2235 #7 0x00203080 in js_Invoke (cx=0x89e200, argc=1, vp=0x22795284, flags=0) at jsinterp.cpp:1371 #8 0x001ea22a in js_fun_call (cx=0x89e200, argc=1, vp=0x2279524c) at /Users/smaug/mozilla/hg/mozilla/js/src/jsfun.cpp:1946 #9 0x001fcf76 in js_Interpret (cx=0x89e200) at jsops.cpp:2235 #10 0x00203080 in js_Invoke (cx=0x89e200, argc=3, vp=0x2815a300, flags=0) at jsinterp.cpp:1371 #11 0x111e52b1 in nsXPCWrappedJSClass::CallMethod (this=0x572790, wrapper=0x333e0d90, methodIndex=3, info=0x8e3270, nativeParams=0xbfffd61c) at /Users/smaug/mozilla/hg/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1671 #12 0x111df343 in nsXPCWrappedJS::CallMethod (this=0x333e0d90, methodIndex=3, info=0x8e3270, params=0xbfffd61c) at /Users/smaug/mozilla/hg/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:570 #13 0x003a8314 in PrepareAndDispatch (self=0x273273c0, methodIndex=<value temporarily unavailable, due to optimizations>, args=0xbfffd6f4) at /Users/smaug/mozilla/hg/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 #14 0x003a8496 in nsXPTCStubBase::Stub3 (this=0x273273c0) at xptcstubsdef.inc:1 #15 0x0039c0a4 in nsTimerImpl::Fire (this=0x3a8290) at /Users/smaug/mozilla/hg/mozilla/xpcom/threads/nsTimerImpl.cpp:435 filename is again nsSessionStore.js and lineno 1539

Got this again. filename is again nsSessionStore.js and lineno 1539 and stack the same.

This distinctive stack with two array_extra entries is made by this code in nsSessionStore.js: this._windows[aWindow.__SSi].tabs.forEach(function(aTabData) { aTabData.entries.forEach(extractHosts); }); The crash occurs in js_Interpret, interpreting the extractHosts function: function extractHosts(aEntry) { if (/^https?:\/\/(?:[^@\/\s]+@)?([\w.-]+)/.test(aEntry.url)) { if (!hosts[RegExp.$1] && _this._checkPrivacyLevel(_this._getURIFromString(aEntry.url).schemeIs("https"))) { hosts[RegExp.$1] = true; } } else if (/^file:\/\/([^\/]*)/.test(aEntry.url)) { hosts[RegExp.$1] = true; } if (aEntry.children) { aEntry.children.forEach(extractHosts); } } The first `aEntry.children` compiles to the bytecode instruction: 00111: getargprop 0 "children" We get a property cache hit, then crash. More details to come I hope.

I'm working on this bug and/or a closely related one (not clear yet) in bug 519363. Feel free to keep posting info here, I'm watching both closely. Does anyone know what kind of object aEntry is? Is it native? Does it have a getter for 'children'?

I believe it's a return value of _serializeHistoryEntry, which is just an Object: var entry = { url: aEntry.URI.spec }; etc.

Crash with a build that includes debugging aids from bug 519363 on Windows. http://crash-stats.mozilla.com/report/index/1051429f-4d25-4e41-9066-6cc752091012

(In reply to comment #19) > However, I have noticed that leading up to a crash, the session.js file > suddenly starts to bork, preventing me from saving the session, and on occasion > preventing the on crash backup from working. > > Might even be something that can only be reproduced on XP. Not sure if Boris' #21 made this clear. I have crashed like this 4 times in the last 3 days on Mac OS X 10.5.8, using Namoroka. The 3rd time I had an issue on restart/restore, with a "Oops! This is embarrassing" error message, and several of the tabs "restored" blank. The 4th time, I got the "Oops!" error message again, and no tabs were restored.

I don't know if what I found is related to this bug but there seems to be a Buffer Overflow on sessionstore.js. Using Process Monitor, the Operation was named 'QuerySecurityFile' and the details were 'DACL 0x20000000' Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b2pre) Gecko/20091026 Namoroka/3.6b2pre Firefox/3.5.3 ID:20091026045753

I've just crashed with js_Interpret, with crass address @ 0x0 (NULL pointer dereference?). However, I have previously seen crashes with 0x8 and other values, as if it were either memory corruption or an uninitialized pointer. Trace @ http://crash-stats.mozilla.com/report/index/bp-f223b531-c665-4afd-ba76-754ba2091031

One thing I forgot: OS is Windows 7.

re comment 38, you're misinterpreting the output. and it isn't relevant, the bug is in spidermonkey not file io

Seems like this is currently #1 topcrasher in FF3.6b1. Is there anything I could help here. I still get this once a day or so.

(In reply to comment #42) > Seems like this is currently #1 topcrasher in FF3.6b1. Um, I may have misinterpret the stacks. The #1 topcrasher is perhaps some other JS crash

(In reply to comment #43) > > Seems like this is currently #1 topcrasher in FF3.6b1. > Um, I may have misinterpret the stacks. The #1 topcrasher is perhaps some > other JS crash Chris, would you be able to check that? Would be good to know if this crash is our topcrash on 3.6b2 or not. Meanwhile adding the topcrash keyword.

I read though the bug, but I'm still not clear exactly what we looking in the combinations of stack signature(s), crash addresse(s), and common patters in the in stack traces. If someone can summarize that I can try and dig out volume of that pattern. patterns/counts of signature and crash address and release are easy; patterns of similar lines in the stacktraces of many crash reporters are harder. here is the kind of counts that are easy to dig out. host-5-95:crashdata chofmann$ awk -F\t '$1 ~ /js_Interpret/ {print $8,$1,$14}' 20091111* | sort | uniq -c | sort -nr | grep 3.6b1 | head 1458 3.6b1 js_Interpret 0x30000006 117 3.6b1 js_Interpret 0x4 96 3.6b1 js_Interpret 0x0 49 3.6b1 js_Interpret 0x8 34 3.6b1 js_Interpret 0x101ece7 14 3.6b1 js_Interpret 0x340c72 14 3.6b1 js_Interpret 0x1aace7 13 3.6b1 js_Interpret 0x1a4c92 9 3.6b1 js_Interpret 0xc 9 3.6b1 js_Interpret 0x20000002 host-5-95:crashdata chofmann$ awk -F\t '$1 ~ /js_Interpret/ {print $8,$1,$14}' 20091111* | sort | uniq -c | sort -nr | grep 3.6b2 | head 688 3.6b2 js_Interpret 0x30000006 173 3.6b2 js_Interpret 0x20000002 80 3.6b2 js_Interpret 0x20000004 80 3.6b2 js_Interpret 0x0 54 3.6b2 js_Interpret 0x4 9 3.6b2 js_Interpret 0x8 6 3.6b2 js_Interpret 0x3586c2 5 3.6b2 js_Interpret 0x3009c 5 3.6b2 @0x0 | js_Interpret 0x0 4 3.6b2 js_Interpret 0xc host-5-95:crashdata chofmann$ awk -F\t '$1 ~ /js_Interpret/ {print $8,$1,$14}' 20091111* | sort | uniq -c | sort -nr | grep 3.5.5 | head 206 3.5.5 js_Interpret 0x0 88 3.5.5 js_Interpret 0x4 38 3.5.5 js_Interpret 0x8 32 3.5.5 js_Interpret 0x39c17f 30 3.5.5 js_Interpret 0xc 22 3.5.5 js_Interpret 0x10 17 3.5.5 js_Interpret 0x57c17f 13 3.5.5 js_Interpret 0x38c17f 10 3.5.5 js_Interpret 0x3ac17f 10 3.5.5 js_Interpret 0x18 from this quick look it strongly looks like there is a blocking regression from 3.5.x to be solved in this bug, or maybe another one. 3.5.5 has about 47Million users or potentially about 714,202 users in pool of users that are willing to submit crash reports considering an opt-in/throttling factor ((47M * 0.1 ) 0.15) The data above shows dramatically higher crash volumes for this set of js_Interpret 3.6beta signatures over 3.5.5. 3.6b1 and 3.6b2 crash volumes will be harder to compare for the next few days while the beta users transition from older to newer beta, but right before b2 we had about 248k unthrottled users on 3.6b1. now we are at a split of 100k on 3.6b1 and 170k on 3.6b2. the sample of data above is from a day (11/11 in the middle of this transition.

similar kinds of looks for the other signatures in the title of this bug for the same day (nov 11) [@ js_Invoke], [@ js_Array], [@ js_ValueToBoolean] shows the number of crashes in the single digits for any combination of the signature and crash address on 3.5.5, 3.6b1, and 3.6b2

Chris, so "1458 3.6b1 js_Interpret 0x30000006" is our topcrasher? How does the stack look like for this instance? Anything similar to the other signatures of this bug?

(In reply to comment #47) > Chris, so "1458 3.6b1 js_Interpret 0x30000006" is our topcrasher? Note that that particular crash (js_Interpret with crash address 0x30000006) is bug 525028, which is currently fixed on 1.9.2 and trunk, and does not affect 1.9.1.

(In reply to comment #48) > (In reply to comment #47) > > Chris, so "1458 3.6b1 js_Interpret 0x30000006" is our topcrasher? > > Note that that particular crash (js_Interpret with crash address 0x30000006) is > bug 525028, which is currently fixed on 1.9.2 and trunk, and does not affect > 1.9.1. Whoops, what I said above wasn't quite right--it is fixed in tracemonkey, but that change has not been merged to m-c yet. The next merge should fix it on trunk. I just rechecked and confirmed that it stopped happening in the 3.6 beta nightlies when the fix landed there.

I don't think we can block on a meta bug; we should add dependencies to this one and mark those as blockers, instead.

I don't know how this is a meta bug, but I haven't seen this on trunk for awhile.

I had a couple of sporadic crashes in the last week with 3.6 nightly builds but none of them were reproducible. Example: bp-c8fe691d-321a-4c38-be1a-ce8842091114

now that skip list changes are in the distribution of crashes across line numbers gets a bit easier to view. here is a view from 2009 12 08 some areas of concentration are: line count 4424 6 4432 70 4436 381 4438 2 1501 71 1505 9 904 17 908 3 912 10 916 44

Hey Kairo, this bug just doesn't seem useful in it's current form. It's just a top crash that staying around forever because it's not actionable. Do we have different bugs logged for all the variations? Should we?

I think this bug is mostly serving as a bucket that collects a number of different crashes. I'm not sure if those are really closely related to comment #0 of this bug report. I'm also unsure if there's anything actionable here. Not sure if we might need to file bugs on the variations or not, hard to say without a closer look on the full stacks.

Hey Kairo, did we ever log those separate bugs so we can close this one?

I have no clue if separate bugs are better than this cumulative one. If we file several bugs and they are all not actionable anyhow, that's no better in the end. We need the JS engine guys to tell us what action, if any, is best here.

As fas as my experience with these crashes is concerned, this bug is no longer valid.

None of these crash signatures are top crashers.

Given Danial's comment 58, WFM seems reasonable.