Bug 100463 – MathML fuzzing bugs - 1

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: MathML

[Abhishek Arya]

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

[Eric Seidel (no email)]

Ask an ye shall receive?

[Eric Seidel (no email)]

http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/mathml/RenderMathMLSubSup.cpp#L93

A null pointer on that line.

Presumably m_scripts is null.

[Eric Seidel (no email)]

This one should be trivial for Dave (who presumably knows better than I do what m_scripts does) to fix.

[Dave Barton]

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.

[Dave Barton]

(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.)

[Dave Barton]

Created attachment 171109 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 171109 [details]
Patch

LGTM.

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Dave Barton]

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.

[Dave Barton]

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.

[Dave Barton]

Created attachment 171314 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 171314 [details]
Patch

I assume this just for the EWS to chew on?

[Dave Barton]

(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.

[Julien Chaffraix]

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.

[Dave Barton]

*** This bug has been marked as a duplicate of bug 98791 ***