Bug 22797 – REGRESSION: Crash at http://news.cnet.com/8301-17939_109-10119149-2.html

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Ismail Donmez]

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.

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

I have narrowed this down to the range of revisions between the r37300 and r37376 nightlies.

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

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.

[Anders Carlsson]

Created attachment 25958 [details]
Patch

[Cameron Zwarich (cpst)]

Comment on attachment 25958 [details]
Patch

r=me

[Anders Carlsson]

Committed revision 39215.

[Peter Handel]

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

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

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.

[Cameron Zwarich (cpst)]

This new crash reproduces with no plugins, so I will close this bug and use bug 22869 for tracking the new crash.