Bug 119951 – [GTK] 'pure virtual method called' in WebCore::JSNodeOwner::isReachableFromOpaqueRoots

• Component: WebKitGTK
• Status: NEW

[Jochen Sprickerhof]

(Forwarding bug from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719880)

Hi,

I'm getting random, reproducible SIGABRT with the webkitgtk 2.0.4-2+b1 Debian unstable package.
For example:
$ surf https://github.com/ros/rosdistro/issues/1676
clicking on "Hydromedusa Release" results in:

pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.

Downgrading webkitgtk to 1.8.1-4 fixes this.

Cheers Jochen

Same for midori:

$ gdb --args midori https://github.com/ros/rosdistro/issues/1676
GNU gdb (GDB) 7.6 (Debian 7.6-5)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/midori...Reading symbols from /usr/lib/debug/usr/bin/midori...done.
done.
(gdb) r
Starting program: /usr/bin/midori https://github.com/ros/rosdistro/issues/1676
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18-gdb.py", line 59, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named libstdcxx.v6.printers
Traceback (most recent call last):
  File "/usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18-gdb.py", line 59, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named libstdcxx.v6.printers
[New Thread 0x7fffe41d3700 (LWP 780)]
[New Thread 0x7fffa39d0700 (LWP 781)]
[New Thread 0x7fffa31cf700 (LWP 785)]
[New Thread 0x7fffa29ce700 (LWP 786)]
[Thread 0x7fffa29ce700 (LWP 786) exited]
[Thread 0x7fffa31cf700 (LWP 785) exited]
[New Thread 0x7fffa31cf700 (LWP 787)]
[New Thread 0x7fffa29ce700 (LWP 788)]
Fontconfig warning: "/etc/fonts/conf.d/25-wqy-zenhei.conf", line 11: Having multiple values in <test> isn't supported and may not work as expected
[New Thread 0x7fff8bad4700 (LWP 789)]
[New Thread 0x7fff8b2d3700 (LWP 790)]
[New Thread 0x7fff8a1d1700 (LWP 791)]
[New Thread 0x7fff8943e700 (LWP 792)]
[New Thread 0x7fff88c3d700 (LWP 793)]
[New Thread 0x7fff73fff700 (LWP 794)]
[New Thread 0x7fff69abb700 (LWP 795)]
[New Thread 0x7fff692ba700 (LWP 796)]
[New Thread 0x7fff68ab9700 (LWP 800)]
[New Thread 0x7fff63fff700 (LWP 801)]
[New Thread 0x7fff61132700 (LWP 802)]
[New Thread 0x7fff60931700 (LWP 803)]
[New Thread 0x7fff57fff700 (LWP 804)]
[New Thread 0x7fff577fe700 (LWP 805)]
[Thread 0x7fff8943e700 (LWP 792) exited]
[Thread 0x7fff8a1d1700 (LWP 791) exited]
[Thread 0x7fff60931700 (LWP 803) exited]
[Thread 0x7fff692ba700 (LWP 796) exited]
[Thread 0x7fff61132700 (LWP 802) exited]
[Thread 0x7fff69abb700 (LWP 795) exited]
[Thread 0x7fff73fff700 (LWP 794) exited]
[Thread 0x7fff88c3d700 (LWP 793) exited]
[Thread 0x7fff577fe700 (LWP 805) exited]
[Thread 0x7fff68ab9700 (LWP 800) exited]
[Thread 0x7fff63fff700 (LWP 801) exited]
[New Thread 0x7fff63fff700 (LWP 815)]
pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff225c1e5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff225c1e5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff225f398 in __GI_abort () at abort.c:90
#2  0x00007fffe9a0c605 in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007fffe9a0a766 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:38
#4  0x00007fffe9a0a793 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5  0x00007fffe9a0b27f in __cxxabiv1::__cxa_pure_virtual () at ../../../../src/libstdc++-v3/libsupc++/pure.cc:50
#6  0x00007ffff3c9221e in WebCore::JSNodeOwner::isReachableFromOpaqueRoots (this=0x2f9, handle=..., visitor=0x7ffff7eead28) at ../Source/WebCore/dom/EventTarget.h:189
#7  0x00007ffff32f0e95 in JSC::WeakBlock::visit (this=0x2f9, heapRootVisitor=0x7fffffffcef0) at ../Source/JavaScriptCore/heap/WeakBlock.cpp:108
#8  0x00007ffff32ee10b in JSC::MarkedSpace::visitWeakSets (this=0x7ffff7ee21d8, heapRootVisitor=0x7fffffffcef0) at ../Source/JavaScriptCore/heap/WeakSet.h:104
#9  0x00007ffff32e4905 in JSC::Heap::markRoots (this=0x7ffff7ee5428) at ../Source/JavaScriptCore/heap/Heap.cpp:563
#10 0x00007ffff32e6256 in JSC::Heap::collect (this=0x7ffff7ee2058, sweepToggle=DoSweep) at ../Source/JavaScriptCore/heap/Heap.cpp:721
#11 0x00007ffff3c404d2 in WebCore::collect () at ../Source/WebCore/bindings/js/GCController.cpp:42
#12 0x00007ffff4a52622 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x7ffff7e62f30) at ../Source/WebCore/platform/ThreadTimers.cpp:129
#13 0x00007ffff4b9dd62 in WebCore::timeout_cb () at ../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:49
#14 0x00007ffff78d4a03 in g_timeout_dispatch (source=source@entry=0x5555563d4560, callback=<optimized out>, user_data=<optimized out>)
    at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:4413
#15 0x00007ffff78d3ea6 in g_main_dispatch (context=0x555555833fb0) at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
#16 g_main_context_dispatch (context=context@entry=0x555555833fb0) at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
#17 0x00007ffff78d41f8 in g_main_context_iterate (context=0x555555833fb0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
#18 0x00007ffff78d45fa in g_main_loop_run (loop=0x555555863c30) at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
#19 0x00007ffff6e73257 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#20 0x000055555557bd65 in main (argc=1, argv=0x7fffffffe358) at ../midori/main.c:2579
(gdb) 

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libwebkitgtk-1.0-0 depends on:
ii  libatk1.0-0                     2.8.0-2
ii  libc6                           2.17-92
ii  libcairo2                       1.12.14-5
ii  libdbus-1-3                     1.6.12-1
ii  libdbus-glib-1-2                0.100.2-1
ii  libegl1-mesa [libegl1-x11]      9.1.6-2
ii  libenchant1c2a                  1.6.0-10
ii  libfontconfig1                  2.10.2-2
ii  libfreetype6                    2.4.9-1.1
ii  libgail18                       2.24.20-1
ii  libgcc1                         1:4.8.1-9
ii  libgdk-pixbuf2.0-0              2.28.2-1
ii  libgeoclue0                     0.12.99-2
ii  libgl1-mesa-glx [libgl1]        9.1.6-2
ii  libglib2.0-0                    2.36.4-1
ii  libgstreamer-plugins-base1.0-0  1.0.8-1
ii  libgstreamer1.0-0               1.0.8-1
ii  libgtk2.0-0                     2.24.20-1
ii  libharfbuzz-icu0                0.9.19-1
ii  libharfbuzz0a                   0.9.19-1
ii  libicu48                        4.8.1.1-12
ii  libjavascriptcoregtk-1.0-0      2.0.4-2+b1
ii  libjpeg8                        8d-1
ii  libpango-1.0-0                  1.32.5-5+b1
ii  libpangocairo-1.0-0             1.32.5-5+b1
ii  libpangoft2-1.0-0               1.32.5-5+b1
ii  libpng12-0                      1.2.49-4
ii  libsecret-1-0                   0.15-2
ii  libsoup2.4-1                    2.42.2-6
ii  libsqlite3-0                    3.7.17-1
ii  libstdc++6                      4.8.1-9
ii  libwebkitgtk-1.0-common         2.0.4-2
ii  libwebp4                        0.3.0-3
ii  libx11-6                        2:1.6.1-1
ii  libxcomposite1                  1:0.4.4-1
ii  libxdamage1                     1:1.1.4-1
ii  libxfixes3                      1:5.0.1-1
ii  libxml2                         2.9.1+dfsg1-3
ii  libxrender1                     1:0.9.8-1
ii  libxslt1.1                      1.1.28-2
ii  libxt6                          1:1.1.4-1
ii  zlib1g                          1:1.2.8.dfsg-1

Versions of packages libwebkitgtk-1.0-0 recommends:
pn  gstreamer1.0-plugins-base  <none>
pn  gstreamer1.0-plugins-good  <none>

libwebkitgtk-1.0-0 suggests no packages.

-- no debconf information

[Zan Dobersek]

Pretty similar to bug #112266.

Looking at the Debian-provided libraries, there are differences in what symbols are provided. I'll set up a libwebkitgtk-1.0-0 build for starters.

[Zan Dobersek]

I can't reproduce this using surf inside a Debian Sid chroot, performing the given GitHub test case, and I also can't reproduce with the test case from bug #112266 (which seemed to reproduce more consistently than the test case provided in this bug).

The Debian packaging only the API-related symbols, hence the difference in the symbols listing. I don't think this is related to these crashes, though.

[Zan Dobersek]

Although, plenty of symbols get stripped through dh_strip when creating the Debian packages.

For instance, this shows the JSNodeOwner::isReachableFromOpaqueRoots symbol is still present in the built libwebkitgtk-1.0.so:
(sid)zan@strade:~/Dev/webkit/releases/debian/webkitgtk-2.0.4/build-2.0$ objdump -tT .libs/libwebkitgtk-1.0.so | grep JSNodeOwner | grep isReachableFromOpaqueRoots 
00000000004ba1f0 l     F .text	0000000000000259              _ZN7WebCore11JSNodeOwner26isReachableFromOpaqueRootsEN3JSC6HandleINS1_7UnknownEEEPvRNS1_11SlotVisitorE

This symbol, along with many others, is stripped from the packaged shared library.
Gustavo, do you have any insight on this?

[Jochen Sprickerhof]

(In reply to comment #2)
> I can't reproduce this using surf inside a Debian Sid chroot, performing the given GitHub test case, and I also can't reproduce with the test case from bug #112266 (which seemed to reproduce more consistently than the test case provided in this bug).

Given the information in [1], I guess this is a timing problem. Make sure you install a minimal system/chroot to try it. So I can only trigger this without recommend packages installed. Try this:
$ mkdir /srv/chroot/sid/
$ debootstrap sid /srv/chroot/sid/
$ schroot
$ apt-get --no-install-recommends install surf
$ DISPLAY=:0.0 /usr/bin/surf https://github.com/ros/rosdistro/issues/1676

To not trigger this, it's enough to install the recommend gstreamer1.0-plugins-base into the chroot. Not that this is only a workaround, it's not solving the bug.

[1] https://tombarta.wordpress.com/2008/07/10/gcc-pure-virtual-method-called/

[Zan Dobersek]

... and there's the crash. Thanks for the pointers.

Ignore the whole 'but look at the symbols!' charade.

[Zan Dobersek]

This also reproduces in trunk.

Adjusting the title a bit and CC-ing a couple of JSC developers who could possibly take a look at this.

[Zan Dobersek]

Created attachment 209080 [details]
Backtraces for all the threads

Here's the gdb output, containing backtraces for all the threads at the time of the crash.

[Oliver Hunt]

This looks to be a use after free.  Are you able to run under valgrind/asan?  Based on the assertion, and path to assertion land we've lost a ref() of Node (or subclass)

CC'ing antti and kling as they've been playing with object construction recently

[Zan Dobersek]

I've recompiled with disabled JIT, just so Valgrind could process the execution without crashing in JIT-specific code.

The resulting crash is a bit different, though the culprit still seems a FUBAR'd Node object in WebCore::isReachableFromDOM.

Here's the incomplete backtrace for the crashing thread. I'll upload a complete backtrace dump and the Valgrind log file shortly.

#0  0x00007ffff4856db0 in WebCore::Node::dispatchEvent (this=0xa0e190, event=...) at ../Source/WebCore/dom/Node.cpp:2112
#1  0x00007ffff45863cd in WebCore::isReachableFromDOM (jsNode=0x7fff8918fa70, node=0xa0e190, visitor=...)
    at ../Source/WebCore/bindings/js/JSNodeCustom.cpp:114
#2  0x00007ffff458649c in WebCore::JSNodeOwner::isReachableFromOpaqueRoots (this=0x9289d0, handle=..., visitor=...)
    at ../Source/WebCore/bindings/js/JSNodeCustom.cpp:131
#3  0x00007ffff36acf66 in JSC::WeakBlock::visit (this=0x7ffff7eea000, heapRootVisitor=...)
    at ../Source/JavaScriptCore/heap/WeakBlock.cpp:108
#4  0x00007ffff36a795b in JSC::WeakSet::visit (this=0x7fff89180448, visitor=...) at ../Source/JavaScriptCore/heap/WeakSet.h:104
#5  0x00007ffff36a7afe in JSC::MarkedBlock::visitWeakSet (this=0x7fff89180000, heapRootVisitor=...)
    at ../Source/JavaScriptCore/heap/MarkedBlock.h:260
#6  0x00007ffff36a7f7c in JSC::VisitWeakSet::operator() (this=0x7fffffffd040, block=0x7fff89180000)
    at ../Source/JavaScriptCore/heap/MarkedSpace.cpp:71
#7  0x00007ffff36a8ddb in JSC::MarkedAllocator::forEachBlock<JSC::VisitWeakSet> (this=0x7758a0, functor=...)
    at ../Source/JavaScriptCore/heap/MarkedAllocator.h:120
#8  0x00007ffff36a8567 in JSC::MarkedSpace::forEachBlock<JSC::VisitWeakSet> (this=0x7757b0, functor=...)
    at ../Source/JavaScriptCore/heap/MarkedSpace.h:222
#9  0x00007ffff36a735e in JSC::MarkedSpace::visitWeakSets (this=0x7757b0, heapRootVisitor=...)
    at ../Source/JavaScriptCore/heap/MarkedSpace.cpp:144
#10 0x00007ffff369531b in JSC::Heap::markRoots (this=0x775528) at ../Source/JavaScriptCore/heap/Heap.cpp:580
#11 0x00007ffff3695a9b in JSC::Heap::collect (this=0x775528, sweepToggle=JSC::Heap::DoSweep) at ../Source/JavaScriptCore/heap/Heap.cpp:760
#12 0x00007ffff36957b3 in JSC::Heap::collectAllGarbage (this=0x775528) at ../Source/JavaScriptCore/heap/Heap.cpp:713
#13 0x00007ffff4526ff2 in WebCore::collect () at ../Source/WebCore/bindings/js/GCController.cpp:42
#14 0x00007ffff45270de in WebCore::GCController::gcTimerFired (this=0xa6ced0) at ../Source/WebCore/bindings/js/GCController.cpp:77
#15 0x00007ffff4527369 in WebCore::Timer<WebCore::GCController>::fired (this=0xa6ced0) at ../Source/WebCore/platform/Timer.h:114
#16 0x00007ffff44b6c9b in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x6cc9b0) at ../Source/WebCore/platform/ThreadTimers.cpp:129
#17 0x00007ffff44b6b8b in WebCore::ThreadTimers::sharedTimerFired () at ../Source/WebCore/platform/ThreadTimers.cpp:105
#18 0x00007ffff44d36f5 in WebCore::timeout_cb () at ../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:49
#19 0x00007fffeef9ea03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007fffeef9dea6 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007fffeef9e1f8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007fffeef9e5fa in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff2853257 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#24 0x0000000000405b02 in main (argc=1, argv=0x7fffffffde48) at ../Tools/GtkLauncher/main.c:557

[Zan Dobersek]

Created attachment 209186 [details]
Backtraces for all the threads - crash #2 (Node::dispatchEvent)

[Zan Dobersek]

Created attachment 209188 [details]
Valgrind log file

Log output from displaying the crash-causing site under valgrind with --track-origins=yes.

Seems that the uninitialized value that's causing the crashes is coming from the creation of the <audio> tag QualifiedName.

[Zan Dobersek]

Confirmed, with the JIT-less build crashing in Node::dispatchEvent, the event argument in that method is actually pointing to the same address as HTMLNames::audioTag. Odd.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4856db0 in WebCore::Node::dispatchEvent (this=0x9e1630, event=...) at ../Source/WebCore/dom/Node.cpp:2112
warning: Source file is more recent than executable.
2112	    if (event->isMouseEvent())
(gdb) l
2107	    EventDispatcher::dispatchScopedEvent(this, eventDispatchMediator);
2108	}
2109	
2110	bool Node::dispatchEvent(PassRefPtr<Event> event)
2111	{
2112	    if (event->isMouseEvent())
2113	        return EventDispatcher::dispatchEvent(this, MouseEventDispatchMediator::create(adoptRef(toMouseEvent(event.leakRef())), MouseEventDispatchMediator::SyntheticMouseEvent));
2114	#if ENABLE(TOUCH_EVENTS)
2115	    if (event->isTouchEvent())
2116	        return dispatchTouchEvent(adoptRef(toTouchEvent(event.leakRef())));
(gdb) info args
this = 0x9e1630
event = {m_ptr = 0x6bdcc0}
(gdb) p HTMLNames::audioTag
$3 = {m_impl = 0x6bdcc0}

[Zan Dobersek]

(In reply to comment #4)
> To not trigger this, it's enough to install the recommend gstreamer1.0-plugins-base into the chroot. Not that this is only a workaround, it's not solving the bug.
> 

This is actually essential. If the plugins are not installed, MediaPlayer::isAvailable() is returning false.

In the generated HTMLElementFactory.cpp, when HTMLElementFactory::createHTMLElement() is called with the audioTag, WebCore::audioConstructor is called, but it returns 0 since the MediaPlayer::isAvailable() is returning false due to the missing plugins. This causes the creation of the HTMLUnknownElement with the 'audio' tag name.

Later, in WebCore::isReachableFromDOM, this HTMLUnknownElement passes the isHTMLAudioElement test because it has the correct tag name. It's then cast to HTMLAudioElement through toHTMLAudioElement and the crash ensues.

Looking through HTMLElementFactory, constructors for the following HTML elements can return 0, falling back to creating HTMLUnknownElements with the same tag name:
audio, source, track, video - if either MediaPlayer::isAvailiable() or Settings::mediaEnabled is returning false,
content - if RuntimeEnabledFeatures::shadowDOMEnabled() is returning false,
dialog - if ContextFeatures::dialogElementEnabled() is returning false.

[Zan Dobersek]

Created attachment 209335 [details]
Reproducible test case

A reproducible test case that first disables media support through window.internals.settings.setMediaEnabled(false), creates the element through window.createElement('audio') and then garbage-collects it.

I can reproduce crashes under both DumpRenderTree and WebKitTestRunner.

[Gyuyoung Kim]

(In reply to comment #13)
> (In reply to comment #4)
> > To not trigger this, it's enough to install the recommend gstreamer1.0-plugins-base into the chroot. Not that this is only a workaround, it's not solving the bug.
> > 
> 
> This is actually essential. If the plugins are not installed, MediaPlayer::isAvailable() is returning false.
> 
> In the generated HTMLElementFactory.cpp, when HTMLElementFactory::createHTMLElement() is called with the audioTag, WebCore::audioConstructor is called, but it returns 0 since the MediaPlayer::isAvailable() is returning false due to the missing plugins. This causes the creation of the HTMLUnknownElement with the 'audio' tag name.
> 
> Later, in WebCore::isReachableFromDOM, this HTMLUnknownElement passes the isHTMLAudioElement test because it has the correct tag name. It's then cast to HTMLAudioElement through toHTMLAudioElement and the crash ensues.
> 
> Looking through HTMLElementFactory, constructors for the following HTML elements can return 0, falling back to creating HTMLUnknownElements with the same tag name:
> audio, source, track, video - if either MediaPlayer::isAvailiable() or Settings::mediaEnabled is returning false,
> content - if RuntimeEnabledFeatures::shadowDOMEnabled() is returning false,
> dialog - if ContextFeatures::dialogElementEnabled() is returning false.

I file a bug for this issue at Bug 120297.
https://bugs.webkit.org/show_bug.cgi?id=120297