Bug 15846 - REGRESSION (r27387): Memory corruption when running fast/js/kde/delete.html
Summary: REGRESSION (r27387): Memory corruption when running fast/js/kde/delete.html
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.4
: P1 Major
Assignee: Darin Adler
URL:
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2007-11-05 08:48 PST by Alexey Proskuryakov
Modified: 2007-11-06 13:40 PST (History)
4 users (show)

See Also:


Attachments
patch (2.61 KB, patch)
2007-11-05 20:35 PST, Darin Adler
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2007-11-05 08:48:14 PST
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.
Comment 1 Alexey Proskuryakov 2007-11-05 10:03:08 PST
Regressed in <http://trac.webkit.org/projects/webkit/changeset/27387> (change property map data structure for less memory use, better speed).
Comment 2 Mark Rowe (bdash) 2007-11-05 11:21:57 PST
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) 

Comment 3 Darin Adler 2007-11-05 18:55:55 PST
I can probably fix this fast if I turn on hash table consistency checks.
Comment 4 Darin Adler 2007-11-05 20:35:34 PST
Created attachment 17054 [details]
patch
Comment 5 Maciej Stachowiak 2007-11-06 11:53:24 PST
Comment on attachment 17054 [details]
patch

r=me
Comment 6 Darin Adler 2007-11-06 13:40:46 PST
Committed revision 27487.