HTMLFrameSetElement-window-eventListener-attributes.html sometimes crashes on SnowLeopard Release. Unfortunately the bots don't seem to be saving crash logs. :-(
I added this test to the Skipped file in r57731.
There is a good chance that the disabled test is innocent.
In debug mode, fast/dom/Window/HTMLBodyElement-window-eventListener-attributes.html randomly crashes, which may make subsequent tests crash:
run-webkit-tests --repeat-each 100 fast/dom/Window
The debug crash is an assertion failure, ASSERT(m_wrapper || !m_jsFunction) in JSEventListener::jsFunction().
Created attachment 53560 [details]
test (will assert)
(In reply to comment #3)
> There is a good chance that the disabled test is innocent.
> In debug mode,
> fast/dom/Window/HTMLBodyElement-window-eventListener-attributes.html randomly
> crashes, which may make subsequent tests crash:
Should we skip this test instead?
This has now crashed on Windows as well: http://build.webkit.org/results/Windows%20Debug%20(Tests)/r57731%20(12262)/results.html
Created attachment 53570 [details]
Comment on attachment 53570 [details]
Interesting bug. It seems like another solution is to keep the body wrapper alive. Can you and some text to the ChangeLog explaining why this approach is better?
+ window onject
> It seems like another solution is to keep the body wrapper alive.
> Can you and some text to the ChangeLog explaining why this approach is better?
Maybe it's better to explain it here - ChangeLog explains what was done in a patch, not what wasn't done.
The reason I didn't fix this by keeping body wrapper alive was that it would be too subtle and roundabout. But thinking about it now, there is a bigger issue - the body element can be replaced via DOM manipulation, or even adopted by another document.
Also, for posterity - I didn't figure out how the problem and the assertion failure resulted in release mode crashes. There is some chance that the random crashes were something different - if so, we'll hear from them again.