User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.0.04506) Build Identifier: Minefield 2008030607 The main thread dies throwing a stack overflow. This most often happens on a restore, but has also been observed when coming back to session left open overnight. Second try works. Repros on 3b3, Minefield 2008030605 as well. I'll try and capture another instance with debugging symbols available; this one happened before I had found the documentation explaining where to get symbol files. I apologize for the less than complete report. js3250.dll!6be12081() [Frames below may be incorrect and/or missing, no symbols loaded for js3250.dll] js3250.dll!6be12723() js3250.dll!6be121a7() js3250.dll!6be12723() js3250.dll!6be1205c() js3250.dll!6be122cf() js3250.dll!6be12723() js3250.dll!6be1205c() js3250.dll!6be122cf() js3250.dll!6be12723() js3250.dll!6be1205c() js3250.dll!6be122cf() these three repeated to the limits of my stack trace window, guessing at least 500 times. The actual failure happens @ 6BE12070 mov edi,dword ptr [esp+18h] 6BE12074 mov eax,dword ptr [edi] 6BE12076 test eax,eax 6BE12078 mov ebx,dword ptr [esp+14h] 6BE1207C je 6BE1208A 6BE1207E push 0 6BE12080 push eax 6BE12081 push ebx Reproducible: Sometimes Steps to Reproduce: 1. Restart browser after crash or upgrade 2. Pages start loading, cookies demanded, etc 3. Lockup Or: 1) Leave browser alone for 8 hours 2) return 3) discover crash. Actual Results: Browser becomes non-responsive. Eventually windows pops up dialog 'this application has crashed, debug, close' Expected Results: Obviously, I expected it to restore cleanly. First of all, I'm able to repeat this often enought to try various experiements. I'll definitely be trying to track this down in more detail, and will hopefully submit a followup with symbol information. Suggestions are very welcome; I don't know the infrastructure here. Right now I'm going to try and prune my sessionstore.js to see if I can narrow down the culprit to a subset of the billion tabs I had open. I had a lot of tabs open, can attach sessionstore.js if helpful Pretty clean prefs.js, can also attach if helpful. Minimal active extensions, because so few run unmodified on minefield builds. AdBlock2, ScriptBlock. FireBug. Will turn off extensions to see if repro still happens. I've looked at similar bugs, and I don't think they overlap. There were two PDFs in two different tabs, similar to 345626. But they were being blocked fom loading by scriptblock. I was also working on editing a Wikipedia entry, perhaps triggering Bug 340717. It wasn't that long; a screenful of text, max. And the actual failure mode of stack overflow matches neither. Big 417101/417115 happens on exit; my bug seems to happen on startup. But the stack overflow doesn't seem to be happening the same library, and it was marked resolved-fixed already. Thanks for any help you can give me on tracking this one down.
If you use a Mozilla.org binary build you just can send a breakpad crash report and post the id from about:crashes. Do you get this also in the firefox safemode (without addons) ?
I believe I just got the same crash when restoring a session on startup in a (newly-updated) 2008/03/19 nightly on Windows XP SP2. Observed the same behavior, plus watched both times as the firefox.exe process pegged one CPU at 100% and then started allocating an ever-increasing amount of memory until the crash occurred. It hit about 1.2 GB before each crash. Breakpad IDs for both crashes are c82d281c-f66e-11dc-8b0f-001a4bd46e84 26799754-f670-11dc-bb64-001a4bd46e84 Both crashes list the cause as "EXCEPTION_STACK_OVERFLOW" and though the signatures are sllightly different ("js3250.dll@0x2ded8" and "js3250.dll@0x2e239") they both point to js3250.dll. Add-ons loaded (compatibility checking is disabled) are: ColorZilla 1.9 Firebug 1.1.0b12 Html Validator 0.8.4.4 IE View 1.3.7 Live HTTP Headers 0.13.1 View Source Chart 2.5.03 Web Developer 1.1.5 I did not try safe mode, but I did back up to the Minefield build from 2008/03/01 and restored the exact same session without issue. UA from this build is: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030106 Minefield/3.0b4pre I'll try installing subsequent nightly builds until I encounter the crash again and will update this bug again if and when I find one. Assuming I do, I'll also try a safe-mode start to see what happens.
This appears to be triggered by something specific in the profile, possibly sessionrestore.js. I didn't make a copy of my profile until after the 03/01 build worked, and now I am unable to recreate the crash on any build, up to an including: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031905 Minefield/3.0b5pre I assume that after the successful load on the 03/01 build, whatever was triggering the race/overflow/crash was overwritten.
(In reply to comment #3) > I assume that after the successful load on the 03/01 build, whatever was > triggering the race/overflow/crash was overwritten. Andy, thanks for the update. => incomplete because you can't reproduce and reporter never responded
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.