found during the top site test runs on windows 7 on http://www.nme.com Ted's exploitable tools rates this as exploitablity: low DoDeferredRelease<nsISupports*> XPCJSRuntime::GCCallback(JSRuntime*, JSGCStatus) Collect js::GC(JSRuntime*, js::JSGCInvocationKind, js::gcreason::Reason) JS_GC Operating system: Windows NT 6.1.7601 Service Pack 1 CPU: x86 GenuineIntel family 6 model 23 stepping 6 2 CPUs Crash reason: EXCEPTION_ACCESS_VIOLATION_READ Crash address: 0x59a6e905 Thread 0 (crashed) 0 xul.dll!DoDeferredRelease<nsISupports *> [XPCJSRuntime.cpp : 564 + 0x9] eip = 0x684b8836 esp = 0x0029f400 ebp = 0x0029f40c ebx = 0x7ffd4000 esi = 0x010bc068 edi = 0x00000000 eax = 0x099e6c3f ecx = 0x099e6c3f edx = 0x59a6e8fd efl = 0x00210246 Found by: given as instruction pointer in context 1 xul.dll!XPCJSRuntime::GCCallback(JSRuntime *,JSGCStatus) [XPCJSRuntime.cpp : 718 + 0xe] eip = 0x684ad5ae esp = 0x0029f414 ebp = 0x0029f430 Found by: call frame info 2 mozjs.dll!Collect [jsgc.cpp : 4505 + 0x8] eip = 0x6b027081 esp = 0x0029f438 ebp = 0x0029f49c Found by: call frame info 3 mozjs.dll!js::GC(JSRuntime *,js::JSGCInvocationKind,js::gcreason::Reason) [jsgc.cpp : 4524 + 0x16] eip = 0x6b026daa esp = 0x0029f4a4 ebp = 0x0029f4bc Found by: call frame info 4 mozjs.dll!JS_GC [jsapi.cpp : 2945 + 0xc] eip = 0x6af7d538 esp = 0x0029f4c4 ebp = 0x0029f4d0 Found by: call frame info 5 xul.dll!nsXREDirProvider::DoShutdown() [nsXREDirProvider.cpp : 857 + 0x9] eip = 0x67599382 esp = 0x0029f4d8 ebp = 0x0029f510 Found by: call frame info 6 xul.dll!ScopedXPCOMStartup::~ScopedXPCOMStartup() [nsAppRunner.cpp : 1109 + 0xa] eip = 0x675872c7 esp = 0x0029f518 ebp = 0x0029f528 Found by: call frame info 7 xul.dll!ScopedXPCOMStartup::`scalar deleting destructor'(unsigned int) + 0xe eip = 0x675908af esp = 0x0029f530 ebp = 0x0029f534 Found by: call frame info 8 xul.dll!XREMain::XRE_main(int,char * * const,nsXREAppData const *) [nsAppRunner.cpp : 3934 + 0x1e] eip = 0x675903db esp = 0x0029f53c ebp = 0x0029f59c Found by: call frame info 9 xul.dll!XRE_main [nsAppRunner.cpp : 3988 + 0x16] eip = 0x67590905 esp = 0x0029f5a4 ebp = 0x0029f6b8 Found by: call frame info 10 firefox.exe!do_main [nsBrowserApp.cpp : 174 + 0x14] eip = 0x012a22e3 esp = 0x0029f6c0 ebp = 0x0029f814 Found by: call frame info 11 firefox.exe!NS_internal_main(int,char * *) [nsBrowserApp.cpp : 279 + 0xc] eip = 0x012a1d3a esp = 0x0029f81c ebp = 0x0029f9b0 Found by: call frame info 12 firefox.exe!wmain [nsWindowsWMain.cpp : 100 + 0xc] eip = 0x012a1299 esp = 0x0029f9b8 ebp = 0x0029f9e4 Found by: call frame info 13 firefox.exe!__tmainCRTStartup [crtexe.c : 552 + 0x18] eip = 0x012a4def esp = 0x0029f9ec ebp = 0x0029fa34 Found by: call frame info 14 firefox.exe!wmainCRTStartup [crtexe.c : 370 + 0x4] eip = 0x012a4c1f esp = 0x0029fa3c ebp = 0x0029fa3c Found by: call frame info 15 kernel32.dll + 0x4ed6b eip = 0x7665ed6c esp = 0x0029fa44 ebp = 0x0029fa48 Found by: call frame info 16 ntdll.dll + 0x6377a eip = 0x77a6377b esp = 0x0029fa50 ebp = 0x0029fa88 Found by: previous frame's frame pointer 17 ntdll.dll + 0x6374d eip = 0x77a6374e esp = 0x0029fa90 ebp = 0x0029faa0 Found by: previous frame's frame pointer
oh and this crash was found on trunk
Version: unspecified → Trunk
Could you be more specific about the STR? Do I just need to visit http://www.nme.com? Is it Windows-specific? Did it crash in a debug build or an opt build? How reproducible is it?
If we're releasing garbage memory we might be calling virtual methods on it -- would be nice to translate this stack (or a debug crash) into a line-number so we can see what's being read and what's done with it after.
(In reply to Bill McCloskey (:billm) from comment #2) > Could you be more specific about the STR? Do I just need to visit > http://www.nme.com? Is it Windows-specific? Did it crash in a debug build or > an opt build? How reproducible is it? Hey Bill, the latest crash with this signature was in a Debug Build Changeset http://hg.mozilla.org/mozilla-central/rev/87f6f50a0207 an on the url http://www.lfgcomic.com so seems the crash affects multiple sites (not just www.nme.com). I had this crash while running bughunter on the top sites.
There's not much we can do here without a way to reproduce this. If I ran bughunter myself, is it likely that I would hit one of these crashes?
billm, Bughunter is a system where a set of worker machines build Firefox and load urls in the attempt to reproduce crashes and report them to a database where the results can be queried in a web application. Tomcat runs an instance that attempts to test the top sites. I also have an instance that runs in the colo that attempts to reproduce crashes from socorro. I just submitted this particular url and could not reproduce any crashes with today's builds. I checked manually and could not reproduce on windows 7 32bit with today's build either. Assuming this was reproducible, I'll do a bisection to see when it was fixed and will let you know in a bit.
Given the timing, I'm going to assume that this was due to some kind of memory corruption from the landing of IonMonkey that was fixed elsewhere. Please reopen or file a new bug if you see this again.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Has bughunter seen this crash lately? The "See also" bug with a similar signature (bug 791814) was duped to bug 792226 which was duped to bug 793257 which was fixed in late September (Fx 18). That bug was thought to be a regression that started around the time this bug was filed. Is it possible to do bughunter runs using ASAN builds? Much faster than Valgrind and might pop out all sorts of good bugs.
(In reply to Daniel Veditz [:dveditz] from comment #9) > Is it possible to do bughunter runs using ASAN builds? Much faster than > Valgrind and might pop out all sorts of good bugs. yeah working on this.
You need to log in before you can comment on or make changes to this bug.