WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 24133
Crash when loading GMail and stop loading
https://bugs.webkit.org/show_bug.cgi?id=24133
Summary
Crash when loading GMail and stop loading
Adam Treat
Reported
2009-02-24 13:27:51 PST
Loading up Gmail.com and then canceling the load while it is still loading results in a crash and ASSERT: ASSERTION FAILED: docLoader->requestCount() == 0 (../../../../WebCore/loader/loader.cpp:178 void WebCore::Loader::cancelRequests(WebCore::DocLoader*)) Patch forthcoming.
Attachments
Fixes crash
(3.09 KB, patch)
2009-02-24 13:57 PST
,
Adam Treat
no flags
Details
Formatted Diff
Diff
New version that includes a layout test
(5.26 KB, patch)
2009-02-26 10:56 PST
,
Adam Treat
no flags
Details
Formatted Diff
Diff
New version crashes more reliably
(5.92 KB, patch)
2009-02-26 11:52 PST
,
Adam Treat
koivisto
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Adam Treat
Comment 1
2009-02-24 13:57:55 PST
Created
attachment 27933
[details]
Fixes crash I'm trying to come up with reproducible test, but if not this is the fix.
Alexey Proskuryakov
Comment 2
2009-02-25 06:56:20 PST
This is exactly the kind of fix that really needs automated tests. We have some examples of slow loading e.g. in http/tests/incremental
Adam Treat
Comment 3
2009-02-25 07:11:33 PST
I've been working on a test all morning. In fact, I did all of this precisely to try and generate a layout test:
http://trac.webkit.org/changeset/41211
However, now that the Qt port can do such a slow loading tests, I haven't been able to come up with one that causes the crash. Here's why: The theory behind the crash is that if the user stops the loading while the preloader is active, then this results in a crash. However, with a layout test I can not automate this stoppage of loading since I'd have to be able to do it via JavaScript. Well, no JavaScript is executed in this preloading stage. That's the whole point of the preloader actually. While a script is loading the preloader goes ahead and continues tokenizing and initiates the network loading of other resources, but it does not allow to execute scripts out of order. Thus, while a script is loading and the tokenizer is thus blocked, I can not programmatically stop the load via JavaScript. I don't know how to get around this.
Alexey Proskuryakov
Comment 4
2009-02-25 07:16:03 PST
Could preloading be stopped with JS running in a different frame?
Adam Treat
Comment 5
2009-02-26 10:56:17 PST
Created
attachment 28022
[details]
New version that includes a layout test I've added a layout test that crashes reproducibly and reliably without this patch.
Adam Treat
Comment 6
2009-02-26 11:52:04 PST
Created
attachment 28029
[details]
New version crashes more reliably
Darin Adler
Comment 7
2009-02-26 11:53:51 PST
Comment on
attachment 28029
[details]
New version crashes more reliably Too bad we have to add another function to DocLoader! Good fix, though, and great to have a high quality test for it. r=me
Alexey Proskuryakov
Comment 8
2009-02-26 11:57:54 PST
Comment on
attachment 28029
[details]
New version crashes more reliably
> + * http/tests/misc/slow-preload-cancel-expected.txt: Added. > + * http/tests/misc/slow-preload-cancel.html: Added.
Please fix the ChangeLog to mention new files.
> +</script> > \ No newline at end of file
Please add one.
Adam Treat
Comment 9
2009-02-26 12:10:48 PST
Fixed with
r41265
.
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