Bug 15846 – REGRESSION (r27387): Memory corruption when running fast/js/kde/delete.html

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

run-webkit-tests fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html fast/js/kde/delete.html

This crashes for me reliably, although with different crash logs.

When running tests normally, I see many random crashes that presumably have the same cause. Given that buildbot is happy, I suppose that this is easier to reproduce on debug builds.

[Alexey Proskuryakov]

Regressed in <http://trac.webkit.org/projects/webkit/changeset/27387> (change property map data structure for less memory use, better speed).

[Mark Rowe (bdash)]

Running the test twice in a row in gdb under GuardMalloc reliably triggers a crash.  You can do so as follows:

$ gdb --args ./WebKitBuild/Debug/DumpRenderTree LayoutTests/fast/js/kde/delete.html LayoutTests/fast/js/kde/delete.html
(gdb) set env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
(gdb) r


This consistently gives me the following crash and backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xd5925fd8
0x00280bd1 in KJS::UString::Rep::deref (this=0xd5925fd0) at ustring.h:158
158	      ALWAYS_INLINE void deref() { ASSERT(JSLock::lockCount() > 0); if (--rc == 0) destroy(); }
(gdb) bt
#0  0x00280bd1 in KJS::UString::Rep::deref (this=0xd5925fd0) at ustring.h:158
#1  0x00232a91 in KJS::PropertyMap::~PropertyMap (this=0x16da0da4) at property_map.cpp:160
#2  0x00232acb in KJS::PropertyMap::~PropertyMap (this=0x16da0da4) at property_map.cpp:163
#3  0x01eaac67 in KJS::JSObject::~JSObject (this=0x16da0da0) at object.h:99
#4  0x022807aa in KJS::JSGlobalObject::~JSGlobalObject (this=0x16da0da0) at JSGlobalObject.h:29
#5  0x02277b19 in KJS::Window::~Window (this=0x16da0da0) at WebCore/bindings/js/kjs_window.cpp:248
#6  0x01ed0e08 in WebCore::JSDOMWindow::~JSDOMWindow (this=0x16da0da0) at JSDOMWindow.h:31
#7  0x01ed0e39 in WebCore::JSDOMWindow::~JSDOMWindow (this=0x16da0da0) at JSDOMWindow.h:31
#8  0x00269407 in KJS::Collector::sweep<(KJS::Collector::HeapType)0> (currentThreadIsMainThread=true) at collector.cpp:870
#9  0x0023b619 in KJS::Collector::collect () at collector.cpp:960
#10 0x01fbf931 in collect () at WebCore/bridge/JavaScriptStatistics.cpp:44
#11 0x01fbfa0c in WebCore::JavaScriptStatistics::garbageCollect () at WebCore/bridge/JavaScriptStatistics.cpp:75
#12 0x00457d7f in +[WebCoreStatistics garbageCollectJavaScriptObjects] (self=0x540fe0, _cmd=0x14c24) at WebKit/Misc/WebCoreStatistics.mm:78
#13 0x00007512 in main (argc=3, argv=0xbffff610) at WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm:593
(gdb) 

[Darin Adler]

I can probably fix this fast if I turn on hash table consistency checks.

[Darin Adler]

Created attachment 17054 [details]
patch

[Maciej Stachowiak]

Comment on attachment 17054 [details]
patch

r=me

[Darin Adler]

Committed revision 27487.