Created attachment 170816 [details] Testcase 1 Testcase 1: ================================================================= ==20749== ERROR: AddressSanitizer crashed on unknown address 0x000000000000 (pc 0x7fdf04bb8565 sp 0x7fffc2cc73a0 bp 0x7fffc2cc7690 T0) AddressSanitizer can not provide additional info. #0 0x7fdf04bb8564 in WebCore::RenderMathMLSubSup::addChild(WebCore::RenderObject*, WebCore::RenderObject*) third_party/WebKit/Source/WebCore/rendering/mathml/RenderMathMLSubSup.cpp:93 #1 0x7fdefda4f886 in WebCore::NodeRendererFactory::createRendererIfNeeded() third_party/WebKit/Source/WebCore/dom/NodeRenderingContext.cpp:263 #2 0x7fdefd9975ec in WebCore::Node::createRendererIfNeeded() third_party/WebKit/Source/WebCore/dom/Node.cpp:1395 #3 0x7fdefd765f07 in WebCore::Element::attach() third_party/WebKit/Source/WebCore/dom/Element.cpp:1004 #4 0x7fdefd340c46 in WebCore::ContainerNode::attachChildren() third_party/WebKit/Source/WebCore/dom/ContainerNode.h:208 #5 0x7fdefd332eee in WebCore::ContainerNode::attach() third_party/WebKit/Source/WebCore/dom/ContainerNode.cpp:707 #6 0x7fdefd766041 in WebCore::Element::attach() third_party/WebKit/Source/WebCore/dom/Element.cpp:1019 #7 0x7fdefd2a889b in WebCore::Node::reattach() third_party/WebKit/Source/WebCore/dom/Node.h:878 #8 0x7fdefd768daf in WebCore::Element::recalcStyle(WebCore::Node::StyleChange) third_party/WebKit/Source/WebCore/dom/Element.cpp:1132 #9 0x7fdefd76a46c in WebCore::Element::recalcStyle(WebCore::Node::StyleChange) third_party/WebKit/Source/WebCore/dom/Element.cpp:1218 #10 0x7fdefd42abc9 in WebCore::Document::recalcStyle(WebCore::Node::StyleChange) third_party/WebKit/Source/WebCore/dom/Document.cpp:1855 #11 0x7fdefd42c520 in WebCore::Document::updateStyleIfNeeded() third_party/WebKit/Source/WebCore/dom/Document.cpp:1903 #12 0x7fdefd406c9a in WebCore::Document::styleRecalcTimerFired(WebCore::Timer<WebCore::Document>*) third_party/WebKit/Source/WebCore/dom/Document.cpp:1788 #13 0x7fdefd621684 in WebCore::Timer<WebCore::Document>::fired() third_party/WebKit/Source/WebCore/platform/Timer.h:106 #14 0x7fdeff73ed26 in WebCore::ThreadTimers::sharedTimerFiredInternal() third_party/WebKit/Source/WebCore/platform/ThreadTimers.cpp:116 #15 0x7fdeff73dfe8 in WebCore::ThreadTimers::sharedTimerFired() third_party/WebKit/Source/WebCore/platform/ThreadTimers.cpp:93 #16 0x7fdee499601c in webkit_glue::WebKitPlatformSupportImpl::DoTimeout() ./webkit/glue/webkitplatformsupport_impl.h:165 #17 0x7fdee499e4cf in base::internal::RunnableAdapter<void (webkit_glue::WebKitPlatformSupportImpl::*)()>::Run(webkit_glue::WebKitPlatformSupportImpl*) ./base/bind_internal.h:134 #18 0x7fdee499e11a in base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (webkit_glue::WebKitPlatformSupportImpl::*)()>, void (webkit_glue::WebKitPlatformSupportImpl*)>::MakeItSo(base::internal::RunnableAdapter<void (webkit_glue::WebKitPlatformSupportImpl::*)()>, webkit_glue::WebKitPlatformSupportImpl*) ./base/bind_internal.h:870 #19 0x7fdee499de27 in base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void (webkit_glue::WebKitPlatformSupportImpl::*)()>, void (webkit_glue::WebKitPlatformSupportImpl*), void (base::internal::UnretainedWrapper<webkit_glue::WebKitPlatformSupportImpl>)>, void (webkit_glue::WebKitPlatformSupportImpl*)>::Run(base::internal::BindStateBase*) ./base/bind_internal.h:1172 #20 0x7fdef0b7752c in base::Callback<void ()>::Run() const ./base/callback.h:391 #21 0x7fdef11c3f6b in base::Timer::RunScheduledTask() base/timer.cc:181 #22 0x7fdef11c4920 in base::BaseTimerTaskInternal::Run() base/timer.cc:46 #23 0x7fdef11c749f in base::internal::RunnableAdapter<void (base::BaseTimerTaskInternal::*)()>::Run(base::BaseTimerTaskInternal*) ./base/bind_internal.h:134 #24 0x7fdef11c70ea in base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (base::BaseTimerTaskInternal::*)()>, void (base::BaseTimerTaskInternal*)>::MakeItSo(base::internal::RunnableAdapter<void (base::BaseTimerTaskInternal::*)()>, base::BaseTimerTaskInternal*) ./base/bind_internal.h:870 #25 0x7fdef11c6de3 in base::internal::Invoker<1, base::internal::BindState<base::internal::RunnableAdapter<void (base::BaseTimerTaskInternal::*)()>, void (base::BaseTimerTaskInternal*), void (base::internal::OwnedWrapper<base::BaseTimerTaskInternal>)>, void (base::BaseTimerTaskInternal*)>::Run(base::internal::BindStateBase*) ./base/bind_internal.h:1172 #26 0x7fdef0b7752c in base::Callback<void ()>::Run() const ./base/callback.h:391 #27 0x7fdef0d94c8d in MessageLoop::RunTask(base::PendingTask const&) base/message_loop.cc:470 #28 0x7fdef0d96afa in MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) base/message_loop.cc:482 #29 0x7fdef0d971b5 in MessageLoop::DoWork() base/message_loop.cc:661 #30 0x7fdef0a8951d in base::MessagePumpGlib::HandleDispatch() base/message_pump_glib.cc:268 #31 0x7fdef0a8b3a5 in (anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) base/message_pump_glib.cc:105 #32 0x7fdedeca5d52 in g_main_dispatch /build/buildd/glib2.0-2.32.3/./glib/gmain.c:2539 Stats: 16M malloced (94M for red zones) by 94118 calls Stats: 1M realloced by 1535 calls Stats: 13M freed by 75985 calls Stats: 0M really freed by 0 calls Stats: 132M (33801 full pages) mmaped in 33 calls mmaps by size class: 10:94185; 11:2047; 12:1024; 13:512; 14:256; 15:128; 16:64; 17:32; 18:32; 19:8; mallocs by size class: 10:91131; 11:1483; 12:957; 13:192; 14:220; 15:87; 16:21; 17:7; 18:18; 19:2; frees by size class: 10:73729; 11:1312; 12:455; 13:173; 14:201; 15:78; 16:13; 17:4; 18:18; 19:2; rfrees by size class: Stats: malloc large: 27 small slow: 848 ==20749== ABORTING
Ask an ye shall receive?
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/mathml/RenderMathMLSubSup.cpp#L93 A null pointer on that line. Presumably m_scripts is null.
This one should be trivial for Dave (who presumably knows better than I do what m_scripts does) to fix.
Created attachment 171075 [details] Reduced test case I'm pretty sure the patch for bug 98791 fixes this. I will check and then mark this bug as a duplicate of that one.
(In reply to comment #3) > This one should be trivial for Dave (who presumably knows better than I do what m_scripts does) to fix. m_scripts is the anonymous box containing the subscript and/or superscript, by the way. (It's needed because a subscript and superscript are supposed to line up vertically, to be cool looking mathematics.)
Created attachment 171109 [details] Patch
Comment on attachment 171109 [details] Patch LGTM.
Comment on attachment 171109 [details] Patch Rejecting attachment 171109 [details] from commit-queue. New failing tests: mathml/msubsup-fuzz.html Full output: http://queues.webkit.org/results/14618237
Comment on attachment 171109 [details] Patch Attachment 171109 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14611631 New failing tests: mathml/msubsup-fuzz.html
Is there a way I can see the stack trace of these failures? Should I mark the test as possibly crashing and try to land it that way? Would the stack trace be available on a bot then, but not on the cr-linux EWS bot? Sorry I can't figure out how to analyze the EWS failures. The test passed locally for me.
I uploaded the mathml/msubsup-fuzz.html test that crashed on chromium-ews (chromium-xvfb), and it passes on a cr-linux bot: http://build.webkit.org/builders/Chromium%20Linux%20Release%20%28Tests%29/builds/40442/steps/layout-test/logs/stdio contains: 13:38:48.368 14284 worker/3 mathml/msubsup-fuzz.html passed Is it possible that chromium-ews (chromium-xvfb) had not yet gotten the patch for bug 98791, http://trac.webkit.org/changeset/132735 landed at 10/27/12 11:18:34? Or maybe mathml/msubsup-fuzz.html is really flaky, and will sometimes crash? I think I will upload another patch to this bug, and see if it passes cr-linux.
Created attachment 171314 [details] Patch
Comment on attachment 171314 [details] Patch I assume this just for the EWS to chew on?
(In reply to comment #13) > (From update of attachment 171314 [details]) > I assume this just for the EWS to chew on? I figure we'll wait to see what the EWS says first. If it passes, I guess I'd like a r+ so we can cq+ it and hopefully close the bug.
Comment on attachment 171314 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171314&action=review It looks like this entry was removed in http://trac.webkit.org/changeset/133691 so the patch is moot. > LayoutTests/mathml/msubsup-fuzz.html:4 > + // This test crashed once on cr-linux-ews. See webkit.org/b/100463. Not sure if it helps to add a comment as no one investigated the failure. > LayoutTests/platform/chromium/TestExpectations:1974 > +# webkit.org/b/100463 mathml/msubsup-fuzz.html [ Crash Pass ] -- is this ok now? We don't usually comment an entry: if it passes, we should just remove it.
*** This bug has been marked as a duplicate of bug 98791 ***