Closed Bug 351468 Opened 19 years ago Closed 19 years ago

Firefox trunk shutdown topcrash [@ 0x772f2f3a] [@ nsAttrAndChildArray::Clear] since 2006-08-16

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED DUPLICATE of bug 353881

People

(Reporter: ispiked, Unassigned)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

This crash is #4 on the FirefoxTrunk topcrash list. It seems to have started appearing on 2006-08-16. The comments seem to say that this crash occurs on shutdown. Check-ins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=mozilla%2Fcontent&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-15+03&maxdate=2006-08-16-05&cvsroot=%2Fcvsroot Incident ID: 22157706 Stack Signature 0x772f2f3a 5bf5c75b Product ID FirefoxTrunk Build ID 2006081604 Trigger Time 2006-08-16 09:49:33.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module URL visited User Comments Since Last Crash 5368 sec Total Uptime 5368 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace 0x772f2f3a nsAttrAndChildArray::Clear [mozilla\content\base\src\nsattrandchildarray.cpp, line 648]
could this be a regression or leftover from Bug 348586 which also crashed at 0x772---- but was resolved between the 16th nightly and 17th nightly ?
Possible... The regression range for this bug matches when the workaround for bug 348586 got backed out, no?
bug 348586 seems unlikely to me. The location of the crash in that bug was nsVoidArray's dtor in a garbage collection, resulting from heap corruption that happened far earlier due to a bug with |delete| in spidermonkey.
If someone is able to crash on this one with easy (i can't), I have the following zipped builds for the regressionwindow from comment #0: firefox-3.0a1.en-US.win32_20060815_0530pdt firefox-3.0a1.en-US.win32_20060815_0816pdt firefox-3.0a1.en-US.win32_20060815_0908pdt firefox-3.0a1.en-US.win32_20060815_1330pdt firefox-3.0a1.en-US.win32_20060815_1608pdt firefox-3.0a1.en-US.win32_20060815_2210pdt please e-mail (gmail) me and I'll send them so you can figure out when this exactly started
The other question I have is .... is this still happening? Especially in 2006-08-31 or later builds?
(tbID from moz.forum), yes it seems so. Incident ID: 22950878 Stack Signature 0x772f2f3a 5bf5c75b Product ID FirefoxTrunk Build ID 2006090504 Trigger Time 2006-09-06 00:55:01.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module URL visited User Comments Since Last Crash 13488 sec Total Uptime 13488 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace 0x772f2f3a nsAttrAndChildArray::Clear [mozilla\content\base\src\nsattrandchildarray.cpp, line 648]
I've got a theory on this. According to the talkback below this is crashing in urlmon.dll. And that's more or less part of IE isn't it? Well my point is that there was a bad patch in August that caused IE to crash. http://blog.washingtonpost.com/securityfix/2006/08/microsoft_rereleases_internet.html And they reissued that patch shortly thereafter. Maybe that problem is tripping us too. This crash first a appeared shortly after August's patch Tuesday. So this crash should go away when people update their windows. Acording to the site I gave above this only affects XP SP1 and Win2k. TB23008113 Incident ID: 23008113 Stack Signature urlmon.dll + 0x92f3a (0x772f2f3a) 5056a2f4 Product ID FirefoxTrunk Build ID 2006090304 Trigger Time 2006-09-07 10:02:06.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module urlmon.dll + (00092f3a) URL visited google.com/ig; gmail.com/browsing User Comments Since Last Crash 56168 sec Total Uptime 102341 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace urlmon.dll + 0x92f3a (0x772f2f3a)
The only crash on close that I saw repeatedly was when I downloaded a file, downloaded another file, and while the files were still loading, closed the window. It then crashed when the first download was finished. I could never get a talkback for that crash nor could I reproduce it but it happened 5 or 6 times in the last few weeks. Might be extension related.
Maybe it is only a coincidence but the stack address 0x772f2f3a is "://w" written in text. This address appears always in the context given below. If it is not a coincidence a buffer overrun can cause this. 0x772f2f3a nsAttrAndChildArray::Clear [mozilla\content\base\src\nsattrandchildarray.cpp, line 648] Started also on 20060816 for me. I have also a few crashes with unusable stacktrace.
(In reply to comment #9) > The only crash on close that I saw repeatedly was when I downloaded a file, > downloaded another file, and while the files were still loading, closed the > window. It then crashed when the first download was finished. I could never get > a talkback for that crash nor could I reproduce it but it happened 5 or 6 times > in the last few weeks. Might be extension related. > Hurray, I could reproduce it this time and even a talkback: TB23036434G. When I used the session restore to continue the pages and the downloads it did not crash anymore :(. Just what I said: can't reproduce it deliberately.
Can someone try running under valgrind or something? Do we now have a good idea of the checkin range in bonsai? If so, could someone put that in the URL field?
Flags: blocking1.9?
It does look like urlmon.dll is involved in the bogus MS patch from August. http://www.securiteam.com/windowsntfocus/5IP0N2KJFO.html http://secunia.com/advisories/21557 And MS repatched this a third time as part of their September patches. http://it.slashdot.org/article.pl?sid=06/09/12/2113218
One other question. Is the crash Windows-only? Or are people seeing it on other platforms too?
I searched Talkback for all crashes on trunk with nsAttrAndChildArray::Clear within their top five frames. There were 367 crashes that matched this criteria. There were three crashes on Linux (TB23146615, TB23093138, TB23087188, and TB23053521) and two crashes on Mac (TB22488161 and TB22464759). The rest were on Windows. Interestingly, not all of them had the top frame of 0x772f2f3a. Some had random addresses (e.g. TB23500085) and others were [@ 0x00000000] (TB22512344). All of the Windows crashes seem to be in the format: [random address] nsAttrAndChildArray::Clear whereas the Mac and Linux crashes are slightly more detailed. That said, the majority of these crashes started happening in 2006-08-16-04 builds and later. Only two crashes happened before that (TB21337392 and TB20484662 ).
Depends on: 353881
bug 353881 seems to have fixed this one. *** This bug has been marked as a duplicate of 353881 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.9?
Whiteboard: [blocking1.9a1?]
Crash Signature: [@ 0x772f2f3a] [@ nsAttrAndChildArray::Clear]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.