New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 24 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Dec 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 75604: http://js.revsci.net/gateway/gw.js appears to cause tabs to crash @ WebCore::CachedResource::errorOccurred()

Reported by oliver.h...@gmail.com, Mar 10 2011

Issue description

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/
                       
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 3.x: OK
       IE 7/8: OK

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

What is the expected result?

The tab should load correctly.

What happens instead?

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
 

Comment 1 by oliver.h...@gmail.com, Mar 10 2011

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

Comment 2 by skerner@chromium.org, Mar 10 2011

Labels: FeedbackRequested
What if you disable experimental features in about:labs?

Comment 3 by oliver.h...@gmail.com, Mar 10 2011

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

Comment 4 by sunandt@chromium.org, Mar 10 2011

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.

Comment 5 by oliver.h...@gmail.com, Mar 11 2011

Still happens. Crash IDs are:

2d18864910c3d9da
dc684723f752477a

Let me know if you need any more info!

Comment 6 by eroman@chromium.org, Mar 14 2011

Labels: -Area-Undefined -FeedbackRequested Area-WebKit Crash
Status: Untriaged
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

Comment 7 by thestig@chromium.org, Mar 18 2011

Cc: dglazkov...@gtempaccount.com

Comment 8 by dglazkov@chromium.org, Mar 18 2011

Cc: simonjam...@gtempaccount.com
James, does this look like your fault?

Comment 9 by simonjam@chromium.org, Mar 18 2011

Cc: a deleted user
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.

Comment 10 by lafo...@chromium.org, Mar 19 2011

Labels: -Crash bulkmove Stability-Crash
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/
                       
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 3.x: OK
       IE 7/8: OK

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

What is the expected result?

The tab should load correctly.

What happens instead?

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

Comment 11 by sunandt@chromium.org, May 2 2011

Cc: a deleted user anan...@chromium.org kerz@chromium.org
Labels: -Pri-2 Pri-1 WebKit-Core
Summary: http://js.revsci.net/gateway/gw.js appears to cause tabs to crash @ WebCore::CachedResource::errorOccurred()
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

Comment 12 by simonjam@chromium.org, May 2 2011

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

Comment 13 by sunandt@chromium.org, May 2 2011

Labels: Mstone-12
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.

Comment 14 by jar@chromium.org, May 2 2011

Cc: a deleted user a deleted user jar@chromium.org
Owner: a deleted user
Status: Assigned
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).

Comment 15 by sky@chromium.org, May 3 2011

simon, do you have instant enabled?

Comment 16 by cbentzel@chromium.org, May 3 2011

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

Comment 17 by cbentzel@chromium.org, May 3 2011

Labels: Feature-Preload
Owner: gavinp@chromium.org
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> *)

Comment 18 by cbentzel@chromium.org, May 3 2011

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

Comment 19 by gavinp@google.com, May 3 2011

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

Comment 20 by eroman@chromium.org, May 3 2011

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)

Comment 21 by gavinp@google.com, May 4 2011

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.

Comment 22 by gavinp@chromium.org, May 4 2011

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.

Comment 23 by tonyg@chromium.org, May 4 2011

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.

Comment 24 by jar@chromium.org, May 4 2011

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.

Comment 25 by gavinp@chromium.org, May 27 2011

 Issue 83810  has been merged into this issue.

Comment 26 by gavinp@chromium.org, May 27 2011

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.

Comment 27 by tburkard@google.com, May 31 2011

Gavin, did this get fixed for M13?

Thanks.

Comment 28 by gavinp@google.com, May 31 2011

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.

Comment 29 by k...@google.com, Jun 1 2011

Labels: -Mstone-12 MovedFrom12 Mstone-14
This bug was targeted for M12, but not fixed.  Moving out to M14.

Comment 30 by simonjam@chromium.org, Jun 2 2011

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

Comment 31 by gavinp@google.com, Jun 2 2011

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?

Comment 32 by simonjam@chromium.org, Jun 2 2011

Labels: -MovedFrom12 -Mstone-14 Mstone-12
Status: Fixed
Works for me.

Comment 33 by gavinp@chromium.org, Jun 23 2011

 Issue 85828  has been merged into this issue.

Comment 34 by gavinp@chromium.org, Jun 23 2011

Labels: -Mstone-12 Mstone-13
Status: Assigned
It seems it's back, and with a vengeance.

Comment 35 by gavinp@chromium.org, Jun 23 2011

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

Comment 36 by simonjam@chromium.org, Jun 23 2011

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.

Comment 37 by gavinp@chromium.org, Jun 23 2011

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.

Comment 38 by mihaip@chromium.org, Jun 24 2011

 Issue 87375  has been merged into this issue.

Comment 39 by gavinp@chromium.org, Jul 13 2011

Cc: gavinp@chromium.org
 Issue 84125  has been merged into this issue.

Comment 40 by japhet@chromium.org, Aug 24 2011

 Issue 92916  has been merged into this issue.

Comment 41 by japhet@chromium.org, Aug 24 2011

Cc: japhet@chromium.org

Comment 42 by gavinp@google.com, Aug 25 2011

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.

Comment 43 by simonjam@chromium.org, Aug 25 2011

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.

Comment 44 by gavinp@google.com, Aug 25 2011

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.

Comment 45 by simonjam@chromium.org, Aug 25 2011

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.

Comment 46 by gavinp@chromium.org, Aug 26 2011

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

Comment 47 by dharani@google.com, Sep 1 2011

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

Comment 48 by gavinp@chromium.org, Sep 6 2011

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.

Comment 49 by rtenneti@chromium.org, Sep 7 2011

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

Comment 50 by gavinp@chromium.org, Sep 9 2011

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.

Comment 51 by dharani@google.com, Oct 4 2011

any updates? thanks!

Comment 52 by kareng@google.com, Oct 4 2011

 Issue 98865  has been merged into this issue.

Comment 53 by gavinp@chromium.org, Oct 4 2011

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.

Comment 54 by gavinp@chromium.org, Oct 4 2011

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

Comment 55 by gavinp@google.com, Oct 13 2011

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.

Comment 56 by gavinp@google.com, Oct 13 2011

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.

Comment 57 by gavinp@google.com, Oct 14 2011

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?

Comment 58 by Deleted ...@, Oct 19 2011

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.

Comment 59 by kareng@google.com, Oct 20 2011

Labels: -Mstone-13 Mstone-15 ReleaseBlock-Stable
gavin i see this as top crasher on beta now.

Comment 61 by laforge@google.com, Oct 24 2011

Labels: Merge-Requested

Comment 62 by laforge@google.com, Oct 24 2011

Labels: -Merge-Requested Merge-Approved

Comment 63 by japhet@chromium.org, Oct 24 2011

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?

Comment 64 by laforge@google.com, Oct 24 2011

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

Comment 65 by bugdroid1@chromium.org, Oct 31 2011

Project Member
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
------------------------------------------------------------------------

Comment 66 by bugdroid1@chromium.org, Oct 31 2011

Project Member

Comment 67 by laforge@google.com, Nov 2 2011

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?

Comment 69 by japhet@chromium.org, Nov 2 2011

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

Comment 70 by dharani@google.com, Nov 2 2011

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

Comment 71 by bugdroid1@chromium.org, Nov 7 2011

Project Member
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
------------------------------------------------------------------------

Comment 72 by bugdroid1@chromium.org, Nov 7 2011

Project Member
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
------------------------------------------------------------------------

Comment 73 by bugdroid1@chromium.org, Nov 7 2011

Project Member
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
------------------------------------------------------------------------

Comment 74 by bugdroid1@chromium.org, Nov 7 2011

Project Member
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
------------------------------------------------------------------------

Comment 75 by bugdroid1@chromium.org, Nov 7 2011

Project Member
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
------------------------------------------------------------------------

Comment 76 by laforge@google.com, Nov 8 2011

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

Comment 77 by gavinp@chromium.org, Nov 8 2011

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

Comment 78 by laforge@google.com, Nov 8 2011

Labels: Merge-Requested
word

Comment 79 by laforge@google.com, Nov 8 2011

Labels: -Merge-Requested Merge-Approved

Comment 80 by gavinp@chromium.org, Nov 15 2011

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

Comment 81 by laforge@google.com, Nov 15 2011

Labels: -Merge-Approved Merge-Merged-912
Updating to Merge-Merge to reflect the status based on logs.

Comment 82 by laforge@google.com, Nov 30 2011

Fixed?

Comment 83 by gavinp@chromium.org, Dec 5 2011

Status: Fixed
Fixed.

Comment 84 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 85 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-WebKit -WebKit-Core -Feature-Preload -Mstone-16 Cr-Content Cr-Content-Core M-16 Cr-Conent-Preload

Comment 86 by bugdroid1@chromium.org, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 87 by laforge@google.com, Mar 20 2013

Labels: -Cr-Conent-Preload Cr-Content-Preload

Comment 88 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 89 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content-Preload Cr-Internals-Preload

Comment 90 by ashej...@chromium.org, Jun 11 2014

Labels: hasTestcase

Sign in to add a comment