HTML5 parsing build crashes in image cache [@ nsRefPtr<imgCacheEntry>]

RESOLVED INVALID

Status

()

Core
ImageLib
--
critical
RESOLVED INVALID
9 years ago
6 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

({crash})

Other Branch
x86
Mac OS X
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Created attachment 366787 [details]
Stack trace

Build: https://build.mozilla.org/tryserver-builds/2009-03-11_02:26-hsivonen@iki.fi-try-239988a4248/hsivonen@iki.fi-try-239988a4248-firefox-try-mac.dmg

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.
Severity: normal → critical
Keywords: crash
Summary: HTML5 parsing build crashes in image cache → HTML5 parsing build crashes in image cache [@ nsRefPtr<imgCacheEntry>]
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.
(Reporter)

Comment 2

9 years ago
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.
(Reporter)

Comment 3

9 years ago
I resynced with the trunk at rev 1c6248da98ac. Now this crash no longer occurs.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

9 years ago
Reopening. Now I'm seeing this at
http://software.hixie.ch/utilities/js/live-dom-viewer/
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 5

9 years ago
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.
(Reporter)

Comment 6

9 years ago
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.
(Reporter)

Comment 9

9 years ago
Yes, I have a Linux-setup. I resolved the other crash today and will now focus on trying understand this one.
(Reporter)

Comment 10

9 years ago
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.
(Reporter)

Comment 11

9 years ago
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...)
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → INVALID
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.
(Assignee)

Updated

6 years ago
Crash Signature: [@ nsRefPtr<imgCacheEntry>]
You need to log in before you can comment on or make changes to this bug.