WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
12634
REGRESSION: crash loading web archive
https://bugs.webkit.org/show_bug.cgi?id=12634
Summary
REGRESSION: crash loading web archive
Jim Correia
Reported
2007-02-06 09:56:33 PST
Load the attached web archive into the nightly build (19418). After it is done loading, hit reload. Crashes with backtrace: 0 com.apple.WebCore 0x013e21aa WebCore::ResourceRequest::updateResourceRequest() const + 10 (ResourceRequest.cpp:194) 1 com.apple.WebCore 0x013e2378 WebCore::ResourceRequest::url() const + 18 (ResourceRequest.cpp:50) 2 com.apple.WebCore 0x013a41b2 WebCore::FrameLoader::commitProvisionalLoad(WTF::PassRefPtr<WebCore::PageCache>) + 348 (FrameLoader.cpp:2302) 3 com.apple.WebCore 0x013a8027 WebCore::DocumentLoader::commitIfReady() + 71 (PassRefPtr.h:45) 4 com.apple.WebCore 0x013a8135 WebCore::DocumentLoader::finishedLoading() + 25 (DocumentLoader.cpp:285) 5 com.apple.WebCore 0x0139c4fb WebCore::FrameLoader::finishedLoading() + 53 (FrameLoader.cpp:2517) 6 com.apple.WebCore 0x013ab832 WebCore::MainResourceLoader::didFinishLoading() + 34 (MainResourceLoader.cpp:302) 7 com.apple.WebCore 0x013ac099 WebCore::MainResourceLoader::continueAfterContentPolicy(WebCore::PolicyAction, WebCore::ResourceResponse const&) + 1173 (MainResourceLoader.cpp:235) 8 com.apple.WebCore 0x013ac18f WebCore::MainResourceLoader::continueAfterContentPolicy(WebCore::PolicyAction) + 107 (MainResourceLoader.cpp:250) 9 com.apple.WebCore 0x0139b338 WebCore::FrameLoader::continueAfterContentPolicy(WebCore::PolicyAction) + 492 (RefPtr.h:41) 10 com.apple.WebKit 0x00376fc2 -[WebFramePolicyListener receivedPolicyDecision:] + 56 (RefPtr.h:41) 11 com.apple.WebKit 0x003740cd -[WebFramePolicyListener use] + 41 (WebFrameLoaderClient.mm:1216) This works on Safari 2.0.4/419.3 on 10.4.8.
Attachments
Test file mentioned in body of report.
(752.57 KB, application/x-webarchive)
2007-02-06 09:57 PST
,
Jim Correia
no flags
Details
Complete crash log
(22.49 KB, text/plain)
2007-02-06 09:58 PST
,
Jim Correia
no flags
Details
Stack trace from crash described in Comment #9
(4.83 KB, text/plain)
2007-02-07 07:39 PST
,
David Kilzer (:ddkilzer)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jim Correia
Comment 1
2007-02-06 09:57:56 PST
Created
attachment 12974
[details]
Test file mentioned in body of report.
Jim Correia
Comment 2
2007-02-06 09:58:23 PST
Created
attachment 12975
[details]
Complete crash log
David Kilzer (:ddkilzer)
Comment 3
2007-02-06 10:27:38 PST
I can't reproduce this with a local debug build of WebKit
r19433
with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037). Jim, were you connected to the internet when you loaded the webarchive? Did you get a pop-up when you opened the webarchive, or do you have pop-ups disabled?
Jim Correia
Comment 4
2007-02-06 10:40:54 PST
Yes. I was connected to the internet. Yes, Safari's popup blocker is enabled. (However, turning it off doesn't seem to avoid the problem.)
Maciej Stachowiak
Comment 5
2007-02-06 23:26:24 PST
<
rdar://problem/4981000
>
Jim Correia
Comment 6
2007-02-07 05:56:12 PST
(In reply to
comment #3
)
> I can't reproduce this with a local debug build of WebKit
r19433
with Safari > 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037).
FWIW, I just reproduced this on 10.4.8 (8L2127/Intel) with Safari 2.0.4 running against
r19441
.
David Kilzer (:ddkilzer)
Comment 7
2007-02-07 06:25:02 PST
(In reply to
comment #6
)
> FWIW, I just reproduced this on 10.4.8 (8L2127/Intel) with Safari 2.0.4 running > against
r19441
.
Jim, does this happen every time you load the webarchive, or just some times?
Jim Correia
Comment 8
2007-02-07 06:31:40 PST
Sometimes. For that particular web archive, the first load always works here, and it crashes on reload.
David Kilzer (:ddkilzer)
Comment 9
2007-02-07 07:38:10 PST
I finally got this to crash after reloading (basically opening the webarchive once, closing its window, doing some other things in Safari+WebKit, and then loading the webarchive in a new window once again). I still can't get exact steps to reproduce, but I did get it to crash once. Reproduced using a local debug build of WebKit
r19458
with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). Here is the assertion failure console message: ASSERTION FAILED: m_state == FrameStateProvisional (/Users/ddkilzer/Projects/Cocoa/WebKit/WebCore/loader/FrameLoader.cpp:2322 transitionToCommitted) Segmentation fault
David Kilzer (:ddkilzer)
Comment 10
2007-02-07 07:39:46 PST
Created
attachment 13003
[details]
Stack trace from crash described in
Comment #9
Maciej Stachowiak
Comment 11
2007-02-09 03:31:45 PST
I tried many times and could not reproduce with
r19525
.
Jim Correia
Comment 12
2007-02-09 06:29:48 PST
This is still crashing reliably for me here with the stack trace in my original report. (This is different from Dave's stack trace.) I'm running Safari 2.0.4 against
r19528
on 10.4.8 as of this writing. Is there any other information which would help?
Jim Correia
Comment 13
2007-02-09 07:23:25 PST
Like mjs and ddkilzer, I was finally able to *not* reproduce the problem. Digging into this further, it appears that it happens on a reload if there is an unsafe javascript attempt to access a different frame. This depends on which the current ad rotation is at cnn.com. When this happens, the following is logged to the console (with javascript exception logging turned on): Unsafe JavaScript attempt to access frame with URL
http://www.cnn.com/
from frame with URL
http://ad.doubleclick.net/adi/N3285.cnn/B1872795.20;dcadv=895178;sz=336x280;click=http://ads.cnn.com/event.ng/Type=click&FlightID=38677&AdID=49897&TargetID=913&Segments=730,2259,2725,2743,2813,3030,3285,3506,3549,3800,4960,5516,5854,6298,6520,6582,6810,7049,7051,7203,7303,7324,7373&Targets=913,8450,1515,3297,3392,8112,10403,10705,10880,10885,10920,10983&Values=30,46,50,61,73,82,91,100,110,150,682,685,686,917,972,1285,1557,1588,1601,1647,1669,1691,1722,2677,2732,2746,4413,4418,4441,5401,47181,47456,47739,49553&RawValues=TLD%2C%253F%2CZIP%2C03101&Redirect=;ord=bftsfid,bcNrpkRmxwtcv
?. Domains must match. After that happens, we crash. Running a debug build yields: ASSERTION FAILED: m_state == FrameStateProvisional (/Users/correia/tmp/WebKit/WebCore/loader/FrameLoader.cpp:2330 transitionToCommitted) Segmentation fault I don't (yet) have a simpler reduction of the problem. Hopefully the additional information is useful.
Jim Correia
Comment 14
2007-02-09 08:30:52 PST
Also, the advertisement in question is using Flash.
Anders Carlsson
Comment 15
2007-02-19 11:41:09 PST
I can not reproduce this at all, no matter how many times I reload. Also, I don't think the unsafe JS error has anything to do with the crash. Closing.
Anders Carlsson
Comment 16
2007-02-19 11:59:06 PST
Jim says he can still reproduce this.
Jim Correia
Comment 17
2007-02-24 09:04:38 PST
I can still reproduce this as of
r19837
, but don't yet have a 100% reduction of the problem (since it seems to depend what ad CNN.com serves up on a given reload.) In the debugger I'm seeing that the ASSERT at the top of FrameLoader::transitionToCommitted fails: ASSERT(m_state == FrameStateProvisional); m_state is already 1/FrameStateCommittedPage. If we return (as we would in a release build) we end up in FrameLoader::commitProvisionalLoad with a nil m_provisionalDocumentLoader, which is used anyway, which is end reason for the crash. I can seem to reproduce this more readily than others, but I'm not an expert on this codebase. I'm happy to do more debugging (how did the FrameLoader get into an unexpected state?) if someone can point me in the right direction.
David Kilzer (:ddkilzer)
Comment 18
2007-02-25 10:18:07 PST
(In reply to
comment #17
)
> I can still reproduce this as of
r19837
, but don't yet have a 100% reduction of > the problem (since it seems to depend what ad CNN.com serves up on a given > reload.) >[...] > I can seem to reproduce this more readily than others, but I'm not an expert on > this codebase. I'm happy to do more debugging (how did the FrameLoader get into > an unexpected state?) if someone can point me in the right direction.
The best thing to do is to try to capture the source (*.swf) of an ad that is causing problems, then combine it with the saved page to create a reproducible test case (in HTML). Do *.swf files normally get preserved in webarchive files?
Anders Carlsson
Comment 19
2007-03-07 23:29:00 PST
Committed revision 20053.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug