Reproducing this bug is kinda tricky,
- Go to http://www.reddit.com/?count=50&after=t3_7im8f
- Let the CNET page load
- Press back button
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:
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]
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]
Comment on attachment 25958 [details]
Committed revision 39215.
Just saw this on r39293:
Thread 0 Crashed:
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:
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.