Created attachment 329032 [details] Stack traces Description of problem: Firefox segfaults when I open it on a Web page that pops up a JavaScript alert during loading. The crash occurs only if the alerting page is the first page I navigate to (not counting about:blank). The problem occurs even in a newly created user account, so it isn't my personal configuration. Version-Release number of selected component (if applicable): firefox-3.0.5-1.fc10.i386 How reproducible: Almost all the time. Steps to Reproduce: 1. Log into a new user account. 2. Start Firefox once and close it. (This step seems to be necessary for the debugging in the next step to work properly.) 3. Now run at the shell: gdb --args /usr/lib/firefox-3.0.5/firefox 'http://mattmccutchen.net/private/crash-firefox.git/?a=project_list' Actual results: Firefox segfaults. I will attach the stack traces for all threads. Expected results: Firefox does not segfault.
i get the following error when try it: [iarly@ski0s ~]$ firefox http://mattmccutchen.net/private/crash-firefox.git/?a=project_list /usr/lib/firefox-3.0.5/run-mozilla.sh: line 131: 4487 Segmentation fault "$prog" ${1+"$@"}
The stacktrace looks nice, I'll try to reproduce it.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208424752 (LWP 15041)] 0x00000400 in ?? () It looks like a memory corruption in nsRefPtr::nsRefPtr() #1 0x018881d9 in nsRefPtr (this=0xbffb0a9c, aRawPtr=0xaa3cf40) at ../../../dist/include/xpcom/nsAutoPtr.h:980 980 mRawPtr->AddRef(); (gdb) disas 0x018881d9 Dump of assembler code for function nsRefPtr: 0x018881ac <nsRefPtr+0>: push ebp 0x018881ad <nsRefPtr+1>: mov ebp,esp 0x018881af <nsRefPtr+3>: sub esp,0x8 0x018881b2 <nsRefPtr+6>: mov edx,DWORD PTR [ebp+8] 0x018881b5 <nsRefPtr+9>: mov eax,DWORD PTR [ebp+12] 0x018881b8 <nsRefPtr+12>: mov DWORD PTR [edx],eax 0x018881ba <nsRefPtr+14>: mov eax,DWORD PTR [ebp+8] 0x018881bd <nsRefPtr+17>: mov eax,DWORD PTR [eax] 0x018881bf <nsRefPtr+19>: test eax,eax 0x018881c1 <nsRefPtr+21>: je 0x18881d9 <nsRefPtr+45> 0x018881c3 <nsRefPtr+23>: mov eax,DWORD PTR [ebp+8] 0x018881c6 <nsRefPtr+26>: mov eax,DWORD PTR [eax] 0x018881c8 <nsRefPtr+28>: mov eax,DWORD PTR [eax] 0x018881ca <nsRefPtr+30>: add eax,0x4 0x018881cd <nsRefPtr+33>: mov edx,DWORD PTR [eax] 0x018881cf <nsRefPtr+35>: mov eax,DWORD PTR [ebp+8] 0x018881d2 <nsRefPtr+38>: mov eax,DWORD PTR [eax] 0x018881d4 <nsRefPtr+40>: mov DWORD PTR [esp],eax 0x018881d7 <nsRefPtr+43>: call edx 0x018881d9 <nsRefPtr+45>: leave 0x018881da <nsRefPtr+46>: ret where edx is: (gdb) info registers edx edx 0x400 1024
Fully reproducible with upstream binaries...
It looks like nsWindow structure attached to GdkWindow and obtained by get_window_for_gdk_window() is already released so firefox tries to AddRef already released memory.
Moved upstream - https://bugzilla.mozilla.org/show_bug.cgi?id=474303
The upstream bug seems to have become private since I last tried to view it. May I have access to view it?