The rest from about:version, in case it helps:

Google Chrome     11.0.696.0 (Official Build 77261) dev
WebKit            534.24 (trunk@80534)
V8                3.2.0.1
User Agent        Mozilla/5.0 (Windows NT 6.0) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.0 Safari/534.24
Command Line      "C:\Users\ohodgson\AppData\Local\Google\Chrome\Application\chrome.exe" --enable-extension-timeline-api --flag-switches-begin --enable-click-to-play --conflicting-modules-check --experimental-location-features --enable-print-preview --flag-switches-end --flag-switches-begin --enable-click-to-play --conflicting-modules-check --experimental-location-features --enable-print-preview --flag-switches-end

What if you disable experimental features in about:labs?

Assuming you mean about:flags, it makes no difference at all.

Can you try disabling extensions(--disable-extensions) as well?

If you haven't enabled crash logging, please enable it going to Wrench > Options > Under the Hood > Check "Automatically send usage stats and crach reports"

Restart Chrome

Reproduce the Crash

Now go to Start > Run > type eventvwr > Application > Open source==chrome(If XP)
Start > Run > type eventvwr > Windows logs > Application > source==chrome(If Vista/Win7)

You should see a crash Id in it. Please post it here. Thanks.

Still happens. Crash IDs are:

2d18864910c3d9da
dc684723f752477a

Let me know if you need any more info!

http://crash/reportdetail?reportid=2d18864910c3d9da


Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x000001bc )

0x5853e296	 [chrome.dll	 - cachedresource.h:185	WebCore::CachedResource::errorOccurred()
0x585e722d	 [chrome.dll	 - asyncscriptrunner.cpp:87	WebCore::AsyncScriptRunner::timerFired(WebCore::Timer<WebCore::AsyncScriptRunner> *)
0x58543a41	 [chrome.dll	 - timer.h:100	WebCore::Timer<WebCore::MediaControls>::fired()
0x586b14dc	 [chrome.dll	 - threadtimers.cpp:112	WebCore::ThreadTimers::sharedTimerFiredInternal()
0x586b144f	 [chrome.dll	 - threadtimers.cpp:90	WebCore::ThreadTimers::sharedTimerFired()
0x58a1a7c8	 [chrome.dll	 - message_loop.cc:367	MessageLoop::RunTask(Task *)
0x58a1a84f	 [chrome.dll	 - message_loop.cc:376	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x58a1abfc	 [chrome.dll	 - message_loop.cc:569	MessageLoop::DoWork()
0x58a309aa	 [chrome.dll	 - message_pump_default.cc:50	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)
0x58a1a749	 [chrome.dll	 - message_loop.cc:342	MessageLoop::RunInternal()
0x58a1a6ce	 [chrome.dll	 - message_loop.cc:315	MessageLoop::RunHandler()
0x58a1a5c2	 [chrome.dll	 - message_loop.cc:239	MessageLoop::Run()
0x58a47cbd	 [chrome.dll	 - renderer_main.cc:314	RendererMain(MainFunctionParams const &)
0x585140e8	 [chrome.dll	 - chrome_main.cc:749	ChromeMain
0x01122212	 [chrome.exe	 - client_util.cc:280	MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x01124444	 [chrome.exe	 - chrome_exe_main_win.cc:46	wWinMain
0x011733c1	 [chrome.exe	 - crt0.c:263	__tmainCRTStartup
0x77eed0e8	 [kernel32.dll	 + 0x0004d0e8]	BaseThreadInitThunk
0x77d619ba	 [ntdll.dll	 + 0x000419ba]	__RtlUserThreadStart
0x77d6198d	 [ntdll.dll	 + 0x0004198d]	_RtlUserThreadStart

(No comment was entered for this change.)

James, does this look like your fault?

Definitely could be. Perhaps errors while downloading scripts cause problems?

I'm gardening today, so I'm not sure when I'll get a chance to take a closer look.

Chrome Version       : 11.0.696.0 (Official Build 77261) dev
URLs (if applicable) : http://www.pistonheads.com/news/default.asp?storyId=23311 (or any other page on that site).                        http://www.guardian.co.uk/
                       
<b>Other browsers tested:</b>
<b>Add OK or FAIL after other browsers where you have tested this issue:</b>
     Safari 5: OK
  Firefox 3.x: OK
       IE 7/8: OK

<b>What steps will reproduce the problem?</b>
1. Visit the above URI and let it load
2. Aw, Snap!

<b>What is the expected result?</b>

The tab should load correctly.

<b>What happens instead?</b>

The tab crashes.

Please provide any additional information below. Attach a screenshot if possible.

If I open the javascript console before the tab crashes, the last two entries are along the lines of this (with a slightly different querysting depending on the site):

GET http://js.revsci.net/gateway/gw.js?csid=E05516 414 (Request-URI Too Large ( The size of the request header is too large. Contact your ISA server administrator.  ))
GET http://js.revsci.net/gateway/gw.js?csid=E05516 414 (Request-URI Too Large ( The size of the request header is too large. Contact your ISA server administrator.  ))

I've disabled all extensions. In about:flags the following are enabled:

Check for known conflicts with 3rd party modules.
Print Preview
Web Page Prerendering. (set to automatic)
Click to play
Experimental location features

I've hit this crash with Google Chrome 12.0.742.16 (Official Build 83695) while typing in omnibox. I was trying to navigate to sublimevideo.net

Report @ http://crash/reportdetail?reportid=53a9ed7215379f4e

This is in the link prefetch code. Who works on that?

I've hit this again now. One more report @ http://crash/reportdetail?reportid=b1adf6f5af3f7d97 This is again while I was trying to type in the omnibox. I have instant enabled. As soon as the google result page tends to appear, renderer crashes.

Given questions about prefetch code... and omnibox loading... I'm adding Sky and Cbentzel. I'll assign to Cbentzel, and let him delegate (or point at the a better owner).

simon, do you have instant enabled?

sunandt: To see if this is prerender vs. instant, could you turn off "Predict network actions to improve page load performance" in Preferences > Under the Hood

Gavin - can you take a look at this?

Top of stack is 

0x67680725	 [chrome.dll	 - cachedresource.h:185]	WebCore::CachedResource::errorOccurred()
0x6794624f	 [chrome.dll	 - htmllinkelement.cpp:420]	WebCore::HTMLLinkElement::onloadTimerFired(WebCore::Timer<WebCore::HTMLLinkElement> *)

given the callstack in #6 and #17 it looks like this may not be prefetch-specific

I think I have a handle on what's happening here...  More soon.

It took a look at http://crash/reportdetail?reportid=2d18864910c3d9da

The crash occurs in CachedResource::errorOccurred() because |this| is NULL. Specifically this line:

chrome_58510000!WebCore::CachedResource::errorOccurred:
5853e296 8b80bc010000    mov     eax,dword ptr [eax+1BCh]    <===== Crash here.
5853e29c c1e803          shr     eax,3
5853e29f 83e007          and     eax,7
5853e2a2 83f803          cmp     eax,3
....


eax = this = 0
Crashes de-referencing 0+0x1bc (this+0x1bc is m_type)

Bad news folks, I think we have a memory sprayer.

Going up a stack frame from the stack frame 53a9ed7215379f4c (one of sunandt's), I find that we have a really confusing HTMLLinkElement one frame up from the crash: it has a zero m_cachedLinkResource, but it's also got a m_relAttribute of prefetch (which makes sense if Sunand was doing a search).  But HTMLLinkElement::process() shouldn't be able to exit having m_cachedLinkResource null.

Are we having our timer in webkit trigger twice?  (the first time would clear m_cachedLinkResource). 

I can't load the minidumps from oliver hodgeson though.

0x01c5e29a	 [chrome.dll	 - cachedresource.h:185]	WebCore::CachedResource::errorOccurred()
0x01d070d3	 [chrome.dll	 - asyncscriptrunner.cpp:87]	WebCore::AsyncScriptRunner::timerFired(WebCore::Timer<WebCore::AsyncScriptRunner> *)
0x02623b8b	 [chrome.dll	 - timer.h:100]	WebCore::Timer<WebCore::AsyncScriptRunner>::fired()
0x01dd1272	 [chrome.dll	 - threadtimers.cpp:112]	WebCore::ThreadTimers::sharedTimerFiredInternal()
0x01dd11e5	 [chrome.dll	 - threadtimers.cpp:90]	WebCore::ThreadTimers::sharedTimerFired()
0x0213af7e	 [chrome.dll	 - message_loop.cc:367]	MessageLoop::RunTask(Task *)
0x0213b005	 [chrome.dll	 - message_loop.cc:376]	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x0213b3b2	 [chrome.dll	 - message_loop.cc:569]	MessageLoop::DoWork()

There's another stack from a recent crash in errorOccurred().  I think it's the same thing: I believe the timer from startOneShot in webkit is firing twice; and in this case the ScriptRunner (what AsyncScriptRunner is called in late builds) makes the same mistake: it follows the zeroed pointer to CachedResource in its vector of late-running scripts, and *blammo*.

My money right now is on startOneShot() being more properly called startTwoShot() on Windows.  I will continue thinking about this.

Nice troubleshooting. Sounds like the same problem as https://bugs.webkit.org/show_bug.cgi?id=56186

A one shot timer firing twice could definitely explain the symptoms.

I'm not sure if this is applicable... but given the stated problem of a "one shot timer firing twice on windows" I'll recall a subtle bug we uncovered in Chromium before it went public, as we revamped the message loop and the delayed-task (timer) code.

It is a mistake to put anything too specific in the Windows message queue as a timer.  Timers in windows are all recurring timers, and will re-fire if not disabled after running.  As a result, a timer event should ONLY be a tickler, to tell the system to check for events to do, and must not be a reference (pointer) to an event that needs processing.  If a pointer is indeed pushed into the WM message queue, and it fires, but then the working thread is suspended before the recurrence is disabled, the event may re-fire.  The re-fire amounts to being re-queued irrevocably (i.e., cancelling the recurrence won't remove the queued event!!).  This specific issue turned out to also be a subtle distinction between XP and newer OS's as I recall, in that it was easier (possible?) to get this re-firing (irrevocable re-queue) on Vista and later.

The solution of course is to never embed a pointer to a delayed task, but only put a pointer to a generic idempotent(?) function that (atomically) checks a queue of delayed tasks to see if anything is eligible to run.

YMMV.... but it is something to look at for a plausible source.

 Issue 83810  has been merged into this issue.

From Dmitry Vyukov in chromium-dev:



HTMLLinkElement::onloadTimerFired() will be called twice if
dispatchEvent() in onloadTimerFired() calls the
CachedResource::checkNotify() recursively (possibly via nested event
loop). It will cause second call to HTMLLinkElement::notifyFinished()
and it will setup second timer. Then it will indeed crash. I am not
sure as to whether it's possible or not in practice. However the
reporter says that the last thing he sees in logs is:
GET http://js.revsci.net/gateway/gw.js?csid=E05516 414 (Request-URI
Too Large ( The size of the request header is too large. Contact your
ISA server administrator.  ))
GET http://js.revsci.net/gateway/gw.js?csid=E05516 414 (Request-URI
Too Large ( The size of the request header is too large. Contact your
ISA server administrator.  ))
which suggests that it may be the case.

In either case, it's better to detach itself from the cached resource
*before* calling callbacks.

There is another weirdness - TimerBase::m_heapInsertionOrder get it's
values from static counter that is not thread-safe. Such counter works
basically as random number generator. I've investigated the code and I
do *not* see how it can lead to real problems, though. In either case,
std::heap API requires strict weak ordering, so m_heapInsertionOrder
is completely unnecessary.

May somebody verify as to whether it's a possible scenario or not? I
am not all that familiar with chrome sources.

Gavin, did this get fixed for M13?

Thanks.

I believe the stacks showing HTMLLinkElement are fixed now thanks to https://bugs.webkit.org/show_bug.cgi?id=61720 .  However, the ScriptRunner stacks are still outstanding.

This bug was targeted for M12, but not fixed.  Moving out to M14.

I've seen several crashes in AsyncScriptRunner, but that's been refactored away. Are there any crash reports with just ScriptRunner?

Simon,

Yeah, not a single crash with the new ScriptRunner.  And reading the code, I can believe the refactoring fixed it too: AsyncScriptRunner::timerFired() would dereference NULL when called a second time, and AsyncScriptRunner::timerFired() seems careful to avoid that.  Let's call this fixed? 

Works for me.

 Issue 85828  has been merged into this issue.

It seems it's back, and with a vengeance.

(and I'm backburning this until the related  issue 80729  gets landed, as it is occurring much more often)

Both of the crashes are back.

I saw the ScriptRunner crash once using the url in  issue 86920 . It looked like notifyFinished() was being called a second time, but they weren't both on the stack, so I'm not sure. If that did happen, we'd get exactly this crash, so I'll protect against that in ScriptElement and hope it goes away. It feels like I'm just covering this up though, and we're both fighting the same underlying bug.

Coincidentally, the script element that caused the crash always gets a response of 400 Bad request, which isn't far from the 414 that started this bug.

One cause (and not the only one, obviously), is that the addClient() call was occuring twice; which caused two notifyFinished(), which caused two timers, and the first one zeroed the CachedResource and the second one... *blammo*.

I am at this point uncomfortable protecting against it in ScriptElement.  Isn't beta for finding bugs, not covering them up?  My advice is to hold off, and add more consistency checks that crash, to help debugging, rather than guards that protect at this point.

 Issue 87375  has been merged into this issue.

 Issue 84125  has been merged into this issue.

 Issue 92916  has been merged into this issue.

(No comment was entered for this change.)

I've been adding crashes and more data to WebKit to help us track this down.  See https://bugs.webkit.org/show_bug.cgi?id=65563 and https://bugs.webkit.org/show_bug.cgi?id=66939 .

Here's a typical stack for this crash:

Stack Trace (Jump to crashing thread)

Thread 0 *CRASHED* ( SIGSEGV @ 0xbbadbeef )

0x7f813788b975	 [chrome	 - third_party/WebKit/Source/WebCore/dom/ScriptRunner.cpp:59]	WebCore::ScriptRunner::queueScriptForExecution
0x7f8137883e6f	 [chrome	 - third_party/WebKit/Source/WebCore/dom/ScriptElement.cpp:322]	WebCore::ScriptElement::notifyFinished
0x7f8137c32cab	 [chrome	 - third_party/WebKit/Source/WebCore/loader/cache/CachedResource.cpp:152]	WebCore::CachedResource::checkNotify
0x7f8137c3a909	 [chrome	 - third_party/WebKit/Source/WebCore/loader/cache/CachedResourceRequest.cpp:198]	WebCore::CachedResourceRequest::didFail
0x7f8137c22490	 [chrome	 - third_party/WebKit/Source/WebCore/loader/SubresourceLoader.cpp:217]	WebCore::SubresourceLoader::didFail
0x7f81375a3480	 [chrome	 - third_party/WebKit/Source/WebKit/chromium/src/ResourceHandle.cpp:156]	WebCore::ResourceHandleInternal::didFail
0x7f813810c1ca	 [chrome	 - webkit/glue/weburlloader_impl.cc:629]	webkit_glue::WebURLLoaderImpl::Context::OnCompletedRequest
0x7f813752a835	 [chrome	 - ./base/tuple.h:570]	ResourceDispatcher::DispatchMessage
0x7f813752ae8a	 [chrome	 - content/common/resource_dispatcher.cc:279]	ResourceDispatcher::OnMessageReceived
0x7f81374d2fa0	 [chrome	 - content/common/child_thread.cc:149]	ChildThread::OnMessageReceived
0x7f8136e7dd2d	 [chrome	 - base/task.cc:56]	base::subtle::TaskClosureAdapter::Run
0x7f8136e59e52	 [chrome	 - ./base/callback.h:265]	MessageLoop::RunTask
0x7f8136e5a3b7	 [chrome	 - base/message_loop.cc:492]	MessageLoop::DeferOrRunPendingTask
0x7f8136e5a88f	 [chrome	 - base/message_loop.cc:683]	MessageLoop::DoWork
0x7f8136e5f218	 [chrome	 - base/message_pump_default.cc:23]	base::MessagePumpDefault::Run
0x7f8136e5883b	 [chrome	 - base/message_loop.cc:416]	MessageLoop::Run
0x7f813844534e	 [chrome	 - content/renderer/renderer_main.cc:228]	RendererMain
0x7f81366dbc03	 [chrome	 - chrome/app/chrome_main.cc:503]	RunZygote
0x7f81366dc388	 [chrome	 - chrome/app/chrome_main.cc:550]	ChromeMain
0x7f81366dcdc0	 [chrome	 - chrome/app/chrome_exe_main_gtk.cc:46]	main
0x7f81302b3c4c	 [libc-2.11.1.so	 - libc-start.c:226]	__libc_start_main


Every stack I've seen shows a failed request.  Looking at the minidump, I find that cachedScript in ScriptRunner::queueScriptForExecution is null.

Yeah, I've seen the same thing. It only happens on Windows. And only when there's a failure. I haven't been able to reproduce it.

I looked at a couple of minidumps and the state in ScriptElement seems bogus. m_alreadyStarted is false and the other flags seem randomly set. I don't have enough experience with Windows minidumps to know if this is significant.

This crash occurs in OS X, Ubuntu & Windows; that's made me think it's not a memory sprayer, just because it's Too Much Of A Coincidence.  If I'm wrong, please gently correct me...

I've always seen m_alreadyStarted true.  I'm very interested if you see it false, because how on earth do you ever get to call CachedScript::addClient() otherwise?  Hrrrm.

I've seen some odd stuff in minidumps too.  In particular, I found m_cachedScript non-null, but it was NULL in the automatic context of ScriptRunner::queueScriptForExecution.  I want to look at Ubuntu and OS X minidumps to see what they show.

Interesting. The new signature occurs on other platforms but the old signature does not (CachedResource::errorOccurred). I wonder if that tells us anything.

My take from the minidumps was that they couldn't be relied on. The state in there didn't make sense, which lowered my confidence to the point that I didn't want to try to draw conclusions from them.

I had a script set up to replay the known troublesome sites continuously with web-page-replay under the debugger. I'll try that again and see if it catches the new crash signature on Linux.

The latest change to improve telemetry landed: it's r93871 in webkit.  Early next week we should have a canary on this.

This crash is still seen in latest canary (868).

http://crash/reportdetail?reportid=da72242638c7b159

Thread 0 *CRASHED* ( EXCEPTION_BREAKPOINT @ 0x0262e7f6 )

0x0262e7f6	 [chrome.dll	 - scriptrunner.cpp:59	WebCore::ScriptRunner::queueScriptForExecution(WebCore::ScriptElement *,WebCore::CachedResourceHandle<WebCore::CachedScript>,WebCore::ScriptRunner::ExecutionType)
0x026332af	 [chrome.dll	 - scriptelement.cpp:328	WebCore::ScriptElement::notifyFinished(WebCore::CachedResource *)
0x02476d5c	 [chrome.dll	 - cachedresource.cpp:151	WebCore::CachedResource::checkNotify()
0x024d59af	 [chrome.dll	 - cachedscript.cpp:112	WebCore::CachedScript::error(WebCore::CachedResource::Status)
0x024db623	 [chrome.dll	 - cachedresourcerequest.cpp:197	WebCore::CachedResourceRequest::didFail(WebCore::SubresourceLoader *,WebCore::ResourceError const &)
0x02adc573	 [chrome.dll	 - subresourceloader.cpp:216	WebCore::SubresourceLoader::didFail(WebCore::ResourceError const &)
0x0251278a	 [chrome.dll	 - resourceloader.cpp:487	WebCore::ResourceLoader::didFail(WebCore::ResourceHandle *,WebCore::ResourceError const &)
0x01cfa881	 [chrome.dll	 - resourcehandle.cpp:156	WebCore::ResourceHandleInternal::didFail(WebKit::WebURLLoader *,WebKit::WebURLError const &)
0x01c3bd99	 [chrome.dll	 - weburlloader_impl.cc:627	webkit_glue::WebURLLoaderImpl::Context::OnCompletedRequest(net::URLRequestStatus const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,base::Time const &)
0x01d2d042	 [chrome.dll	 - resource_dispatcher.cc:454	ResourceDispatcher::OnRequestComplete(int,net::URLRequestStatus const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,base::Time const &)
0x01d2e047	 [chrome.dll	 - resource_messages.h:153	ResourceMsg_RequestComplete::Dispatch<ResourceDispatcher,ResourceDispatcher,void ( ResourceDispatcher::*)(int,net::URLRequestStatus const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,base::Time const &)>(IPC::Message const *,ResourceDispatcher *,ResourceDispatcher *,void ( ResourceDispatcher::*)(int,net::URLRequestStatus const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,base::Time const &))
0x01d2d332	 [chrome.dll	 - resource_dispatcher.cc:525	ResourceDispatcher::DispatchMessageW(IPC::Message const &)
0x01d2cbf4	 [chrome.dll	 - resource_dispatcher.cc:302	ResourceDispatcher::OnMessageReceived(IPC::Message const &)
0x01d224c4	 [chrome.dll	 - child_thread.cc:149	ChildThread::OnMessageReceived(IPC::Message const &)
0x01fc84cc	 [chrome.dll	 - task.h:349	RunnableMethod<ChromeURLRequestContextGetter,void ( ChromeURLRequestContextGetter::*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &),Tuple1<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::Run()
0x01e4fbca	 [chrome.dll	 - task.cc:56	base::subtle::TaskClosureAdapter::Run()
0x01e4615a	 [chrome.dll	 - message_loop.cc:476	MessageLoop::RunTask(MessageLoop::PendingTask const &)
0x01e461c6	 [chrome.dll	 - message_loop.cc:492	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x01e46541	 [chrome.dll	 - message_loop.cc:682	MessageLoop::DoWork()
0x01e5ec58	 [chrome.dll	 - message_pump_default.cc:50	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)
0x01e460ad	 [chrome.dll	 - message_loop.cc:443	MessageLoop::RunInternal()
0x01e46032	 [chrome.dll	 - message_loop.cc:416	MessageLoop::RunHandler()
0x01e45fc4	 [chrome.dll	 - message_loop.cc:340	MessageLoop::Run()
0x01c4a7b2	 [chrome.dll	 - renderer_main.cc:228	RendererMain(MainFunctionParams const &)
0x01c34871	 [chrome.dll	 - chrome_main.cc:942	ChromeMain
0x00401e13	 [chrome.exe	 - client_util.cc:366	MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x004010c8	 [chrome.exe	 - chrome_exe_main_win.cc:44	wWinMain
0x004592bf	 [chrome.exe	 - crt0.c:263	__tmainCRTStartup
0x7c816fe6	 [kernel32.dll	 + 0x00016fe6]	BaseProcessStart

Yup, it's still happening.  The data I've added to WebKit suggests that notifyFinished() is called twice.  So that gives two possibilities I see:

A. CachedResource::load() is called twice
B. Something very very bad is happening when loads finish.

I bet it's (A) since nothing else is crashy.

The stack in yesterday's beta release are slightly different. The following is the callstack.

http://crash/reportdetail?reportid=11c9f531b74b6f31

Product, Version	 Chrome ,  14.0.835.157

Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x000002bc )

0:000> k
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  
0012f748 02617859 chrome_1c30000!WebCore::CachedResource::errorOccurred [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\loader\cache\cachedresource.h @ 195]
0012f7e0 024b6887 chrome_1c30000!WebCore::ScriptRunner::timerFired+0x18b [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\dom\scriptrunner.cpp @ 114]
0012f7e8 0258e676 chrome_1c30000!WebCore::Timer<WebCore::AnimationControllerPrivate>::fired+0x9 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\platform\timer.h @ 100]
0012f814 01e45dd5 chrome_1c30000!WebCore::ThreadTimers::sharedTimerFiredInternal+0x8e [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\platform\threadtimers.cpp @ 117]
0012f81c 01e46860 chrome_1c30000!`anonymous namespace'::TaskClosureAdapter::Run+0xb [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 105]
0012f848 01e468cc chrome_1c30000!MessageLoop::RunTask+0x72 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 486]
0012f858 01e46c47 chrome_1c30000!MessageLoop::DeferOrRunPendingTask+0x26 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 505]
0012f890 01e5f1b0 chrome_1c30000!MessageLoop::DoWork+0x7d [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 693]
0012f8bc 01e467b2 chrome_1c30000!base::MessagePumpDefault::Run+0xc2 [d:\b\build\slave\chrome-official\build\src\base\message_pump_default.cc @ 50]
0012f8c8 01e46737 chrome_1c30000!MessageLoop::RunInternal+0x31 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 452]
0012f8d0 01e4669c chrome_1c30000!MessageLoop::RunHandler+0x17 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 424]
0012f8f0 01c47036 chrome_1c30000!MessageLoop::Run+0x15 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 349]
0012fc5c 01c348e1 chrome_1c30000!RendererMain+0x303 [d:\b\build\slave\chrome-official\build\src\content\renderer\renderer_main.cc @ 229]
0012fe3c 00401bfd chrome_1c30000!ChromeMain+0x6a4 [d:\b\build\slave\chrome-official\build\src\chrome\app\chrome_main.cc @ 895]
0012fec4 004010fc chrome!MainDllLoader::Launch+0xfc [d:\b\build\slave\chrome-official\build\src\chrome\app\client_util.cc @ 260]
0012ff30 00457210 chrome!wWinMain+0xfc [d:\b\build\slave\chrome-official\build\src\chrome\app\chrome_exe_main_win.cc @ 46]
0012ffc0 7c816fe7 chrome!__tmainCRTStartup+0x112 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 263]
0012fff0 00000000 kernel32!BaseProcessStart+0x23

rtenneti, yeah, we'd expect a different stack on m14, since m15 has crashes on thread earlier to help us diagnose through a CRASH() in webkit.

So, I went through, and considered a few possibilities for causing this crash; and here's my thoughts, based on my code readings:

A. CachedResource::load() is called twice.   I don't believe this is possible, since ScriptElement::requestScript() is guarded by m_alreadyStarted, which should protect double execution.

B. Something very very bad is happening when loads finish.  I can't rule this out; I'm going to try and modify chrome RPC to always fail this way for certain URIs, and see if I can get the same stack?  One path I considered was CachedResource with multiple listeners, and late joiners.  It looks like m_loading guards well against double calls here.

C. CachedResource::addClient() is called twice.  Again, m_alreadyStarted guard.

I'm going to ask if anyone at Apple is seeing this crash.

    

any updates? thanks!

 Issue 98865  has been merged into this issue.

Yes, there's some progress.  I just added a new facility to WebKit for tracking stacks; I'll land something this week that uses that facility to track the zeroing of the cached resource, and once that shows up in canaries, we can begin a new round of speculation as to the cause of this bug.

 http://trac.webkit.org/changeset/96595  <-- the webkit facility

Also, re: comment 50, Apple told me they were not seeing this crash.

I've now used the new stack-saving facility to successfully grab and deconstruct a stack from this bug.  So the crashing stack is:


0013f59c 02a6b439 chrome_1c30000!WebCore::ScriptRunner::queueScriptForExecution+0x12 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\dom\scriptrunner.cpp @ 59]
0013f5bc 02864ca1 chrome_1c30000!WebCore::ScriptElement::notifyFinished+0x54 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\dom\scriptelement.cpp @ 345]
0013f5ec 02ba2226 chrome_1c30000!WebCore::CachedResource::checkNotify+0x2a [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\loader\cache\cachedresource.cpp @ 150]
0013f5f4 028f9090 chrome_1c30000!WebCore::CachedScript::error+0x21 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\loader\cache\cachedscript.cpp @ 113]
0013f60c 02ba4aa0 chrome_1c30000!WebCore::CachedResourceRequest::didFail+0x85 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\loader\cache\cachedresourcerequest.cpp @ 208]
0013f620 0297af8b chrome_1c30000!WebCore::SubresourceLoader::didFail+0x2b [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\loader\subresourceloader.cpp @ 210]
0013f62c 023b920a chrome_1c30000!WebCore::ResourceLoader::didFail+0x33 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webcore\loader\resourceloader.cpp @ 462]
0013f658 0219532c chrome_1c30000!WebCore::ResourceHandleInternal::didFail+0x35 [d:\b\build\slave\chrome-official\build\src\third_party\webkit\source\webkit\chromium\src\resourcehandle.cpp @ 165]
0013f720 01c4170b chrome_1c30000!webkit_glue::WebURLLoaderImpl::Context::OnCompletedRequest+0xf6 [d:\b\build\slave\chrome-official\build\src\webkit\glue\weburlloader_impl.cc @ 628]
0013f740 01c42842 chrome_1c30000!ResourceDispatcher::OnRequestComplete+0x45 [d:\b\build\slave\chrome-official\build\src\content\common\resource_dispatcher.cc @ 455]
0013f798 01c419fb chrome_1c30000!ResourceMsg_RequestComplete::Dispatch<ResourceDispatcher,ResourceDispatcher,void (__thiscall ResourceDispatcher::*)(int,net::URLRequestStatus const &,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,base::Time const &)>+0x4d [d:\b\build\slave\chrome-official\build\src\content\common\resource_messages.h @ 155]
0013f7c4 01c412bd chrome_1c30000!ResourceDispatcher::DispatchMessageW+0x4f [d:\b\build\slave\chrome-official\build\src\content\common\resource_dispatcher.cc @ 525]
0013f7e0 01c40282 chrome_1c30000!ResourceDispatcher::OnMessageReceived+0xbb [d:\b\build\slave\chrome-official\build\src\content\common\resource_dispatcher.cc @ 303]
0013f7f8 01d7d4c3 chrome_1c30000!ChildThread::OnMessageReceived+0x1b [d:\b\build\slave\chrome-official\build\src\content\common\child_thread.cc @ 142]
0013f804 01d5c5df chrome_1c30000!RunnableMethod<CloudPrintProxyBackend::Core,void (__thiscall CloudPrintProxyBackend::Core::*)(std::vector<printing::PrinterBasicInfo,std::allocator<printing::PrinterBasicInfo> > const &),Tuple1<std::vector<printing::PrinterBasicInfo,std::allocator<printing::PrinterBasicInfo> > > >::Run+0x17 [d:\b\build\slave\chrome-official\build\src\base\task.h @ 374]
0013f80c 01d553e2 chrome_1c30000!base::subtle::TaskClosureAdapter::Run+0xb [d:\b\build\slave\chrome-official\build\src\base\task.cc @ 72]
0013f838 01d5544e chrome_1c30000!MessageLoop::RunTask+0x71 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 483]
0013f848 01d557d4 chrome_1c30000!MessageLoop::DeferOrRunPendingTask+0x26 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 500]
0013f888 01d6e490 chrome_1c30000!MessageLoop::DoWork+0x80 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 687]
0013f8b4 01d5530b chrome_1c30000!base::MessagePumpDefault::Run+0xc2 [d:\b\build\slave\chrome-official\build\src\base\message_pump_default.cc @ 50]
0013f8c0 01d55290 chrome_1c30000!MessageLoop::RunInternal+0x31 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 445]
0013f8c8 01d55222 chrome_1c30000!MessageLoop::RunHandler+0x17 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 417]
0013f8e8 021a2f7a chrome_1c30000!MessageLoop::Run+0x15 [d:\b\build\slave\chrome-official\build\src\base\message_loop.cc @ 342]
0013fc64 01d77143 chrome_1c30000!RendererMain+0x31e [d:\b\build\slave\chrome-official\build\src\content\renderer\renderer_main.cc @ 229]
0013fc78 01d774d9 chrome_1c30000!`anonymous namespace'::RunNamedProcessTypeMain+0x41 [d:\b\build\slave\chrome-official\build\src\content\app\content_main.cc @ 252]
0013fe14 01c329a7 chrome_1c30000!content::ContentMain+0x38d [d:\b\build\slave\chrome-official\build\src\content\app\content_main.cc @ 442]
0013fe44 00401e08 chrome_1c30000!ChromeMain+0x32 [d:\b\build\slave\chrome-official\build\src\chrome\app\chrome_main.cc @ 28]
0013fec4 004010c9 chrome!MainDllLoader::Launch+0xf3 [d:\b\build\slave\chrome-official\build\src\chrome\app\client_util.cc @ 347]
0013ff30 0045a1c8 chrome!wWinMain+0xc9 [d:\b\build\slave\chrome-official\build\src\chrome\app\chrome_exe_main_win.cc @ 36]
0013ffc0 7c817077 chrome!__tmainCRTStartup+0x112 [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 263]
0013fff0 00000000 kernel32!BaseProcessStart+0x23

but, perhaps most interestingly, the stack when the value is zeroed is:

0. WTFGetBacktrace()
1. WebCore::CachedResource::checkNotify()
2. WebCore::CachedResource::error()
3. WebCore::SubresourceLoader::didReceiveData()
4. WebCore::ResourceLoader::didReceiveData()
5. WebCore::ResourceHandleInternal::didReceiveData()
6. ResourceDispatcher::OnReceivedData()
7. ResourceDispatcher::DispatchMessageW()  <---- FROM THIS POINT STACKS ARE IDENTICAL
8. ResourceDispatcher::OnMessageReceived()
... (lots of Run/PostTask stuffs)

So from comment 50 above, something bad is happening at load finish.  The question now is:

Are two messages being sent to WebKit from the Chrome network stack, or is one message to WebKit causing two notifyFinshed() events.  Stay tuned, and I'll update when I know.

Uh, duh, it's clearly two messages: ReceivedData and RequestComplete.  However, the last ReceivedData is completing the request implicitly, so the second one is crashing us.

The earlier OnDataReceived is erroring out due to the response code being >= 400, the code is found in CachedResourceRequest::didReceiveData (not on the older stack, due to a tail call optimization in SubresourceLoader::didReceiveData().

This erroring calls directly into CachedResource::error(), and that's the call that nulls.  The request completing in an error state causes the double trouble.

This should be enough to construct a reproduction: most interesting to me is that Safari doesn't seem to experience this crash, so is our RequestComplete message logic broken, and we should avoid it when we error out this way, or is the logic that errors out in CachedResourceRequest::didReceiveData() broken?  Or something else?

I'm running Chromium on Ubuntu 11.10 I had no issues with Chromium until just today.  The browser works fine except when I click on the sign in link on Google.com  The dialog box appears to log in, then suddenly dis-appears, crashes.

gavin i see this as top crasher on beta now. 

Its fixed in 15.0.874.102.

http://crash/search?query=product%3A%22Chrome%22+version%3A%2215.0.874.102%22+crashed_thread_label%3A%22WebCore%3A%3AScriptRunner%3A%3AqueueScriptForExecution%28WebCore%3A%3AScriptElement+*%2CWebCore%3A%3ACachedResourceHandle%3CWebCore%3A%3ACachedScript%3E%2CWebCore%3A%3AScriptRunner%3A%3AExecutionType%29%22

Please merge this in M16 as well. Thanks for fixing!

(No comment was entered for this change.)

(No comment was entered for this change.)

How urgently is a fix needed for M16?  Is there any chance we could wait for the proper fix to land on trunk and merge that instead?

Proper fix is fine w/ me, could someone create a separate bug and mark it as a ReleaseBlocker for Beta?

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=107949

------------------------------------------------------------------------
r107949 | gavinp@chromium.org | Mon Oct 31 07:36:06 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=107949&r2=107948&pathrev=107949
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit/async_script_abort_on_end.html?r1=107949&r2=107948&pathrev=107949
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=107949&r2=107948&pathrev=107949
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=107949&r2=107948&pathrev=107949
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=107949&r2=107948&pathrev=107949
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=107949&r2=107948&pathrev=107949
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=107949&r2=107948&pathrev=107949

Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Review URL: http://codereview.chromium.org/8404001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=107957

------------------------------------------------------------------------
r107957 | gavinp@chromium.org | Mon Oct 31 08:23:34 PDT 2011

Changed paths:
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=107957&r2=107956&pathrev=107957
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=107957&r2=107956&pathrev=107957
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=107957&r2=107956&pathrev=107957
 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=107957&r2=107956&pathrev=107957
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=107957&r2=107956&pathrev=107957
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=107957&r2=107956&pathrev=107957

Revert 107949 - Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Review URL: http://codereview.chromium.org/8404001

TBR=gavinp@chromium.org
Review URL: http://codereview.chromium.org/8427003
------------------------------------------------------------------------

Once we get a trunk/M17 Dev build w/ this change, I'm open to considering it for merge to M16.  How are you feeling about the patch?

Unfortunately, I still see this crash in 925.0

http://crash/search?query=product%3A%22Chrome%22+version%3A%2217.0.925.0%22+crashed_thread_label%3A%22WebCore%3A%3AScriptRunner%3A%3AqueueScriptForExecution%28WebCore%3A%3AScriptElement+*%2CWebCore%3A%3ACachedResourceHandle%3CWebCore%3A%3ACachedScript%3E%2CWebCore%3A%3AScriptRunner%3A%3AExecutionType%29%22

925.0's webkit version is ~200 revisions too early to get the fix.

Oops.. my bad! webkit roll for 925 is r98752 and 926 is r98966. We have to wait for next canary build to verify this bug.

http://trac.webkit.org/changeset/98987

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108864

------------------------------------------------------------------------
r108864 | gavinp@chromium.org | Mon Nov 07 07:02:13 PST 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=108864&r2=108863&pathrev=108864
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit/async_script_abort_on_end.html?r1=108864&r2=108863&pathrev=108864
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=108864&r2=108863&pathrev=108864
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=108864&r2=108863&pathrev=108864
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=108864&r2=108863&pathrev=108864
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=108864&r2=108863&pathrev=108864
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=108864&r2=108863&pathrev=108864

Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107949

Review URL: http://codereview.chromium.org/8404001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108865

------------------------------------------------------------------------
r108865 | gavinp@chromium.org | Mon Nov 07 07:13:24 PST 2011

Changed paths:
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=108865&r2=108864&pathrev=108865
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=108865&r2=108864&pathrev=108865
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=108865&r2=108864&pathrev=108865
 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=108865&r2=108864&pathrev=108865
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=108865&r2=108864&pathrev=108865
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=108865&r2=108864&pathrev=108865

Revert 108864 - Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107949

Review URL: http://codereview.chromium.org/8404001

TBR=gavinp@chromium.org
Review URL: http://codereview.chromium.org/8479031
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108868

------------------------------------------------------------------------
r108868 | gavinp@chromium.org | Mon Nov 07 07:42:54 PST 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=108868&r2=108867&pathrev=108868
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit/async_script_abort_on_end.html?r1=108868&r2=108867&pathrev=108868
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=108868&r2=108867&pathrev=108868
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=108868&r2=108867&pathrev=108868
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=108868&r2=108867&pathrev=108868
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=108868&r2=108867&pathrev=108868
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=108868&r2=108867&pathrev=108868

Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107949

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108864

Review URL: http://codereview.chromium.org/8404001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108870

------------------------------------------------------------------------
r108870 | gavinp@chromium.org | Mon Nov 07 07:49:38 PST 2011

Changed paths:
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=108870&r2=108869&pathrev=108870
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=108870&r2=108869&pathrev=108870
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=108870&r2=108869&pathrev=108870
 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=108870&r2=108869&pathrev=108870
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=108870&r2=108869&pathrev=108870
 D http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=108870&r2=108869&pathrev=108870

Revert 108868 - Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107949

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108864

Review URL: http://codereview.chromium.org/8404001

TBR=gavinp@chromium.org
Review URL: http://codereview.chromium.org/8494011
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=108878

------------------------------------------------------------------------
r108878 | gavinp@chromium.org | Mon Nov 07 09:03:57 PST 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.cc?r1=108878&r2=108877&pathrev=108878
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit/async_script_abort_on_end.html?r1=108878&r2=108877&pathrev=108878
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/net/url_request_abort_on_end_job.h?r1=108878&r2=108877&pathrev=108878
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/content_tests.gypi?r1=108878&r2=108877&pathrev=108878
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/webkit?r1=108878&r2=108877&pathrev=108878
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=108878&r2=108877&pathrev=108878
 A http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/webkit_browsertest.cc?r1=108878&r2=108877&pathrev=108878

Add a browsertest for  bug 75604 

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107949

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108864

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108868

Review URL: http://codereview.chromium.org/8404001
------------------------------------------------------------------------

Based on the commit from Monday, is this something we should be looking to merge to the Beta branch this week?

Yes, Anthony, I strongly suggest it.  Just give me the word, and I'll do it.

word

(No comment was entered for this change.)

Merged into webkit branch 912, http://trac.webkit.org/changeset/100218

Updating to Merge-Merge to reflect the status based on logs.

Fixed?

Fixed.