Created attachment 366787 [details] Stack trace Build: https://build.mozilla.org/tryserver-builds/2009-03-11_02:firstname.lastname@example.orgemail@example.com Steps to reproduce: 1) Install the tryserver build or pull from rev 239988a4248b over at http://hg.mozilla.org/users/mrbkap_mozilla.com/html5parsing/ . 2) Load http://www.cnn.com/ 3) Maybe load something else like http://www.aol.com/ or try to close the windows if step #2 alone doesn't crash. Actual results: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000c0000003 Crashed Thread: 0 Thread 0 Crashed: 0 XUL 0x0141c4ca void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) + 3508554 Expected results: No crash. Additional info: The crash occurs before and after taking revs 14bc4dbf10cb and d85e2a66d940 from the trunk. I can't reproduce the crash with trunk nightlies. The crash stacks don't show any involvement of the HTML5 parser. However, the HTML5 parser may cause different timing for image loads. Perhaps it isn't worthwhile to track this down now if it only affects the HTML5 parsing repo, but instructions to bypass the affected image cache code (bug 482667 maybe) would be appreciated, since currently this makes HTML5 parsing builds very crashy.
This crash looks similar to the one in bug 455555 comment 26. If I'm interpreting the comments correctly, it was fixed by adding a file to packages-static.
I merged the trunk as of rev 19d25e2a170f (2009-03-19 20:39 -0700) into the HTML5 parsing repo, but this crash didn't go away.
I resynced with the trunk at rev 1c6248da98ac. Now this crash no longer occurs.
Reopening. Now I'm seeing this at http://software.hixie.ch/utilities/js/live-dom-viewer/
This is hindering progress on HTML5 parsing. I'd appreciate advice on how I should try to track the cause of the crash down myself or what code I need to #if 0 out to disable the image cache to defer tracking this down.
Created attachment 370834 [details] Valgrind output Valgrind shows that imgCache does questionable things long before the crash (the first imgCache problems were during loading another page that didn't crash yet).
That stack looks bogus to me -- DumpJSStack won't be calling std::__adjust_heap. Note that the code that's on the stack isn't imglib code, it's autogenerated template code for some std usage. You should run valgrind on Linux to make sure you get the correct data, to see if it catches anything else. That stack is entirely bogus though -- NS_StringContainerInit_P doesn't call DumpJSStack. Along with running valgrind on Linux, a useful thing to do would be to just grab a gdb backtrace of the crash, and see if the stack looks sane.
Henri, do you have a linux box you can try this on? I hear valgrind on Mac is still in its early stages and quite likely giving us bogus info here.
Yes, I have a Linux-setup. I resolved the other crash today and will now focus on trying understand this one.
In Valgrind on Linux, I see badness in the memory management of nodes on the list of active formatting elements in the HTML5 parser. It seems I have to rereview carefully my assumptions of implied invariants of the adoption agency algorithm.
I've now fixed the real reason. Thanks, Vlad! (How I wish the stacks on OS X had pointed me to the right place to begin with...)
Great -- you may also want to point Nick Nethercote at this bug, as I know that he's been working on improving the OSX valgrind port. This might be a good testcase for him.