Reproducing this bug is kinda tricky, - Go to http://www.reddit.com/?count=50&after=t3_7im8f - Click the link which says "Firefox, Chrome builds virtually tied for JavaScript speed...." - Let the CNET page load - Press back button Safari crashes.
I'll assign this to myself, at least to find the point of regression. It seems like a memory smasher, because the point at which it crashes is random, and sometimes it even crashes after it has gone back.
I have narrowed this down to the range of revisions between the r37300 and r37376 nightlies.
Here is a link that makes it easier to reproduce: http://www.reddit.com/search?q=firefox%2C+chrome I have verified that this occurs in the range r37338-r37376.
It seems that the crash I was seeing in that range was due to r37370, which was rolled out in r37381. I'll have to investigate this further.
Created attachment 25955 [details] Backtrace If I enable MallocScribble while simply loading the cnet URL in a debug build of ToT WebKit, I get this backtrace every I time.
Created attachment 25958 [details] Patch
Comment on attachment 25958 [details] Patch r=me
Committed revision 39215.
Just saw this on r39293: Thread 0 Crashed: 0 com.apple.JavaScriptCore 0x0044754c WTF::HashTableIterator<JSC::UString::Rep*, JSC::UString::Rep*, WTF::IdentityExtractor<JSC::UString::Rep*>, WTF::StrHash<JSC::UString::Rep*>, WTF::HashTraits<JSC::UString::Rep*>, WTF::HashTraits<JSC::UString::Rep*> > WTF::HashTable<JSC::UString::Rep*, JSC::UString::Rep*, WTF::IdentityExtractor<JSC::UString::Rep*>, WTF::StrHash<JSC::UString::Rep*>, WTF::HashTraits<JSC::UString::Rep*>, WTF::HashTraits<JSC::UString::Rep*> >::find<JSC::UString::Rep*, WTF::IdentityHashTranslator<JSC::UString::Rep*, JSC::UString::Rep*, WTF::StrHash<JSC::UString::Rep*> > >(JSC::UString::Rep* const&) + 252 1 com.apple.JavaScriptCore 0x003be206 JSC::Identifier::remove(JSC::UString::Rep*) + 38 2 com.apple.JavaScriptCore 0x003be28e JSC::UString::Rep::destroy() + 30 3 com.apple.JavaScriptCore 0x004ccc4b JSC::Structure::~Structure() + 299 4 com.apple.JavaScriptCore 0x00459d8c JSC::JSObject::~JSObject() + 140 5 com.apple.JavaScriptCore 0x00457178 unsigned long JSC::Heap::sweep<(JSC::HeapType)0>() + 200 6 com.apple.JavaScriptCore 0x003cd859 JSC::Heap::collect() + 169 7 com.apple.WebCore 0x0107e492 WebCore::Timer<WebCore::GCController>::fired() + 82 8 com.apple.WebCore 0x014fe9d9 WebCore::TimerBase::fireTimers(double, WTF::Vector<WebCore::TimerBase*, 0ul> const&) + 137 9 com.apple.WebCore 0x014feaa2 WebCore::TimerBase::sharedTimerFired() + 162 10 com.apple.WebCore 0x014da904 WebCore::timerFired(__CFRunLoopTimer*, void*) + 68 11 com.apple.CoreFoundation 0x9683ab45 CFRunLoopRunSpecific + 4469 12 com.apple.CoreFoundation 0x9683acf8 CFRunLoopRunInMode + 88 13 com.apple.HIToolbox 0x90389480 RunCurrentEventLoopInMode + 283 14 com.apple.HIToolbox 0x90389299 ReceiveNextEventCommon + 374 15 com.apple.HIToolbox 0x9038910d BlockUntilNextEventMatchingListInMode + 106 16 com.apple.AppKit 0x92e983ed _DPSNextEvent + 657 17 com.apple.AppKit 0x92e97ca0 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 18 com.apple.Safari 0x0000808e 0x1000 + 28814 19 com.apple.AppKit 0x92e90cdb -[NSApplication run] + 795 20 com.apple.AppKit 0x92e5df14 NSApplicationMain + 574 21 com.apple.Safari 0x000b9b16 0x1000 + 756502
There seems to be another problem with this page that is not yet fixed. I can reproduce this after a few loads, even using the bytecode interpreter.
This link reproduces the crash a lot better than the one in the title of this bug, although I am pretty sure it is still the same memory corruption: http://news.cnet.com/8301-13579_3-9953533-37.html I am having a lot of trouble reducing this.
This new crash reproduces with no plugins, so I will close this bug and use bug 22869 for tracking the new crash.