"fast/js/select-options-remove-gc.html crashes intermittently on Chromium" Requested by mwenge2 on #webkit.
I can get it to crash twice in every ten runs with: lucid Tools/Scripts/new-run-webkit-tests --chromium --iterations=100 fast/js/select-options-remove-gc.html It occasionally crashes on the bots too: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fjs%2Fselect-options-remove-gc.html http://build.webkit.org/results/Chromium%20Linux%20Release%20(Tests)/r103905%20(27679)/fast/js/select-options-remove-gc-crash-log.txt : base::debug::StackTrace::StackTrace() [0x5b727e] base::(anonymous namespace)::StackDumpSignalHandler() [0x5a00f9] 0x7f71bf8e5af0 0x9c9a10 WebCore::HTMLSelectElement::optionToListIndex() [0x9c9cd5] WebCore::HTMLSelectElement::remove() [0x9ca396] WebCore::removeElement() [0x183cc4b] WebCore::V8HTMLOptionsCollection::removeCallback() [0x183b90f] v8::internal::Builtin_HandleApiCall() [0x67d48d] 0x205cef404402
I can reproduce this on Qt, so it's not port-specific.
Taking, this has my ink all over it.
Created attachment 121010 [details] Patch
Created attachment 121012 [details] Patch
As discussed on IRC, this fixes the wrong problem. We should make sure that reachable elements are not collected, not deal with the aftermath of GC. How did this work in shipping WebKit?
Created attachment 121057 [details] Better patch Reworked the HTMLCollection ownership model to ensure that collections keep their associated element alive.
Created attachment 121058 [details] Better patch
Sam, would love your input on this.
Committed r104373: <http://trac.webkit.org/changeset/104373>
Committed r104383: <http://trac.webkit.org/changeset/104383>