WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
VERIFIED FIXED
9929
REGRESSION: crash on logging in on mijnpostbank.nl
https://bugs.webkit.org/show_bug.cgi?id=9929
Summary
REGRESSION: crash on logging in on mijnpostbank.nl
Joost de Valk (AlthA)
Reported
2006-07-15 02:09:41 PDT
Logging in on mijnpostbank.nl causes a crash, always, with the latest nightly (
r15448
). This is very hard to reproduce since you need a login, which nobody can share. Trouble is, it's also the biggest banking site in the Netherlands, and should be fixed before release. I'll attach a crash log shortly. Steps to reproduce if you have a login: 1. login 2. page starts loading 3. upon being nearly finished with loading, webkit crashes
Attachments
Crash log
(21.32 KB, text/plain)
2006-07-15 02:27 PDT
,
Joost de Valk (AlthA)
no flags
Details
Crashlog with line numbers
(23.61 KB, text/plain)
2006-07-16 03:26 PDT
,
Martijn Broenland
no flags
Details
Activity window
(156.88 KB, image/png)
2006-07-22 00:22 PDT
,
Martijn Broenland
no flags
Details
Crashlog 17105
(20.21 KB, text/plain)
2006-10-18 05:37 PDT
,
Bas
no flags
Details
MijnPostbank.webarchive.zip crashes the webkit but not safari
(19.04 KB, application/zip)
2007-01-30 05:48 PST
,
Bas
no flags
Details
Stack trace when loading MijnPostbank.webarchive on ToT
(1.95 KB, text/plain)
2007-01-30 07:15 PST
,
David Kilzer (:ddkilzer)
no flags
Details
testcase
(20.02 KB, application/zip)
2007-02-07 06:38 PST
,
Bas
no flags
Details
crashlogs of four situations
(20.21 KB, application/zip)
2007-02-07 06:46 PST
,
Bas
no flags
Details
Stack trace from debug build
(1.92 KB, text/plain)
2007-02-07 08:00 PST
,
David Kilzer (:ddkilzer)
no flags
Details
testcase reduced to 2 html files and one dir
(3.91 KB, application/zip)
2007-03-05 15:52 PST
,
Bas
no flags
Details
Further reduction (will crash)
(305 bytes, text/html)
2007-03-07 14:48 PST
,
mitz
no flags
Details
Patch, without change log and regression test
(1.81 KB, patch)
2007-03-07 15:47 PST
,
mitz
no flags
Details
Formatted Diff
Diff
Patch
(9.09 KB, patch)
2007-03-08 05:41 PST
,
mitz
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Joost de Valk (AlthA)
Comment 1
2006-07-15 02:27:24 PDT
Created
attachment 9463
[details]
Crash log
Darin Adler
Comment 2
2006-07-15 06:26:53 PDT
Besides a reduction, which would be the best thing, other things that would be useful: 2) crash log with a debug version that gives line numbers 3) this looks like a nil dereference -- it would be good to know what exactly is nil -- a bit of a gdb session perhaps 4) the version of the nightly where this regressed With one or more of these 4 things we'd have a fighting chance of fixing the bug.
Martijn Broenland
Comment 3
2006-07-16 03:26:59 PDT
Created
attachment 9482
[details]
Crashlog with line numbers Here's a crash log with line numbers.
Martijn Broenland
Comment 4
2006-07-16 03:30:30 PDT
This is wat gdb has to say: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x6c42617a 0x0192f840 in WebCore::Frame::checkCompleted (this=0x2a2738d0) at /Users/tgm/WebKit/WebCore/page/Frame.cpp:763 763 if (!child->d->m_bComplete)
Alexey Proskuryakov
Comment 5
2006-07-17 04:15:28 PDT
One more question: does it
Alexey Proskuryakov
Comment 6
2006-07-17 04:20:47 PDT
Sorry - was going to ask whether removing SafariStand helps, but then noticed that the first crash log is clean.
Martijn Broenland
Comment 7
2006-07-22 00:19:54 PDT
To make matters more interesting, the site did load at least once without crashing today. The next try resulted in a crash though. (Using release 15561 now)
Martijn Broenland
Comment 8
2006-07-22 00:22:49 PDT
Created
attachment 9611
[details]
Activity window This might also be interesting. Somehow always these two images cancel loading. This screenshot was taken when the site did load without crashing.
Alice Liu
Comment 9
2006-08-14 14:08:31 PDT
<
rdar://problem/4680230
>
Alexey Proskuryakov
Comment 10
2006-10-17 09:34:16 PDT
***
Bug 11324
has been marked as a duplicate of this bug. ***
Bas
Comment 11
2006-10-18 05:37:50 PDT
Created
attachment 11133
[details]
Crashlog 17105 I crashed WebKir as well on login to
http://mijn.postbank.nl
Bas
Comment 12
2006-10-24 15:27:51 PDT
With a binary elimination I found the regression date in the nightlies: January 31 2006 WebKit-SVN-
r12480
.dmg works WebKit-SVN-
r12486
.dmg crashes (In reply to
comment #2
)
> Besides a reduction, which would be the best thing, other things that would be > useful: > > 2) crash log with a debug version that gives line numbers > 3) this looks like a nil dereference -- it would be good to know what > exactly is nil -- a bit of a gdb session perhaps > 4) the version of the nightly where this regressed > > With one or more of these 4 things we'd have a fighting chance of fixing the > bug. >
Alexey Proskuryakov
Comment 13
2006-11-02 11:55:55 PST
The only semi-related change between these revisions is Geoff's fix for <
rdar://problem/4135845
>, but I absolutely cannot see how it could introduce such a crash.
Martijn Broenland
Comment 14
2006-11-02 12:40:27 PST
r12480
does crash on mijn.postbank.nl (at least, on my powermac here)
Martijn Broenland
Comment 15
2006-11-02 12:55:17 PST
It appears to be somewhere between 12306 and 12317 here. 12306 works 12317 crashes Confirmed it on several other computers.
Alexey Proskuryakov
Comment 16
2006-11-04 02:08:54 PST
From Frame::checkCompleted(): ------------------------------------------------ // OK, completed. // Now do what should be done when we are really completed. d->m_bComplete = true; checkEmitLoadEvent(); // if we didn't do it before if (d->m_scheduledRedirection != noRedirectionScheduled) { ------------------------------------------------ The crash in
r17105
happened when accessing d->m_scheduledRedirection - apparently, checkEmitLoadEvent() somehow destroys the current frame.
Joost de Valk (AlthA)
Comment 17
2007-01-19 04:45:26 PST
If there were such a thing as a P0, this bug would be in the category, so, ehm, please fix :)
Alexey Proskuryakov
Comment 18
2007-01-19 10:59:21 PST
(In reply to
comment #17
)
> If there were such a thing as a P0, this bug would be in the category, so, ehm, > please fix :)
A reduction would be, um, most helpful ;).
David Kilzer (:ddkilzer)
Comment 19
2007-01-19 12:08:02 PST
Joost, what's the minimum account balance to open an account? Can we start a WebKit fund for such things? :)
David Kilzer (:ddkilzer)
Comment 20
2007-01-19 12:18:06 PST
(In reply to
comment #18
)
> (In reply to
comment #17
) > > If there were such a thing as a P0, this bug would be in the category, so, ehm, > > please fix :) > > A reduction would be, um, most helpful ;).
I'm going to take a wild guess that it's the first page after logging in that is causing the crash. Try the following: 1. Log in using Firefox. 2. Save initial page after logging in as "Web Page, Complete". 3. Open this saved page in WebKit. Hopefully it will crash. 4a. If it crashes, start the reduction process. 4b. If it doesn't crash, try adding a proper <base href=""> tag to the saved HTML document to make sure it's able to load in all of the resources from the original site (Firefox doesn't rewrite URLs in CSS, for example), then reload in WebKit. Hopefully it will crash, and the reduction process may start. If the above doesn't produce a crash in WebKit, then the next step would be to look at intermediate pages being loaded during the redirect process. The LiveHTTPHeaders plug-in for Firefox would be helpful in determining all of the URLs requested during login. Otherwise, a packet tracer (like Ethereal/Wireshark--which currently requires X11 and Xcode to be installed so that it may be built with MacPorts or fink) would be needed to capture everything that happens when logging in.
David Kilzer (:ddkilzer)
Comment 21
2007-01-19 12:57:29 PST
(In reply to
comment #19
)
> Joost, what's the minimum account balance to open an account? Can we start a > WebKit fund for such things? :)
BTW, I was not kidding about the minimum balance. That would be the easiest way to test the issue!
Bas
Comment 22
2007-01-30 02:03:41 PST
(In reply to
comment #20
)
> (In reply to
comment #18
) > > (In reply to
comment #17
) > > > If there were such a thing as a P0, this bug would be in the category, so, ehm, > > > please fix :) > > > > A reduction would be, um, most helpful ;). > > I'm going to take a wild guess that it's the first page after logging in that > is causing the crash. Try the following: > > 1. Log in using Firefox. > 2. Save initial page after logging in as "Web Page, Complete". > 3. Open this saved page in WebKit. Hopefully it will crash. > 4a. If it crashes, start the reduction process. > 4b. If it doesn't crash, try adding a proper <base href=""> tag to the saved > HTML document to make sure it's able to load in all of the resources from the > original site (Firefox doesn't rewrite URLs in CSS, for example), then reload > in WebKit. Hopefully it will crash, and the reduction process may start. > > If the above doesn't produce a crash in WebKit, then the next step would be to > look at intermediate pages being loaded during the redirect process. The > LiveHTTPHeaders plug-in for Firefox would be helpful in determining all of the > URLs requested during login. Otherwise, a packet tracer (like > Ethereal/Wireshark--which currently requires X11 and Xcode to be installed so > that it may be built with MacPorts or fink) would be needed to capture > everything that happens when logging in. >
Use webkit, disable JavaScript Login and when on
https://mijn.postbank.nl/internetbankieren/SesamLoginServlet
enter these urls:
https://mijn.postbank.nl/internetbankieren/jsp/IndexLogon.jsp
https://mijn.postbank.nl/mpb/startframes.do
Save the last page as a webarchive. Enable Javascript, then Webkit will crash and Safari won't
David Kilzer (:ddkilzer)
Comment 23
2007-01-30 04:11:32 PST
(In reply to
comment #22
)
> Use webkit, disable JavaScript > > Login and when on
https://mijn.postbank.nl/internetbankieren/SesamLoginServlet
> enter these urls: > >
https://mijn.postbank.nl/internetbankieren/jsp/IndexLogon.jsp
>
https://mijn.postbank.nl/mpb/startframes.do
> > Save the last page as a webarchive. > > Enable Javascript, then Webkit will crash and Safari won't
Joost, does that give you a way to create a test reduction for the crash? If not, saving the page as "Web Page, Complete" from Firefox, then replacing personal information on the page with "Lorem Ipsum" (or whatever) and attaching the files in a zip archive would allow others to work on reducing it as well.
David Kilzer (:ddkilzer)
Comment 24
2007-01-30 04:12:49 PST
(In reply to
comment #22
)
> Enable Javascript, then Webkit will crash and Safari won't
Bas, nice job on the steps to reproduce and save a webarchive in the process!
Joost de Valk (AlthA)
Comment 25
2007-01-30 04:38:17 PST
Well i don't have an account there, so someone else will have to save it for me... I'd prefer a full source from Firefox btw :)
Bas
Comment 26
2007-01-30 05:22:02 PST
(In reply to
comment #25
)
> Well i don't have an account there, so someone else will have to save it for > me... I'd prefer a full source from Firefox btw :) >
FireFox full source does not crash the WebKit
Bas
Comment 27
2007-01-30 05:48:01 PST
Created
attachment 12790
[details]
MijnPostbank.webarchive.zip crashes the webkit but not safari Hi, I reduced the bug a bit to the point that my personal data is not visible. Luckily the frame on the right (not included) contains the withdrawals & payments, but the frame that crashes WebKit is the left one so I made an archive of that. Now someone needs to work further on this bug... Just drop it on WebKit (a debug build perhaps) and look at the crash.
David Kilzer (:ddkilzer)
Comment 28
2007-01-30 07:14:11 PST
(In reply to
comment #27
)
> Created an attachment (id=12790) [edit] > MijnPostbank.webarchive.zip crashes the webkit but not safari > [...] > Now someone needs to work further on this bug... > Just drop it on WebKit (a debug build perhaps) and look at the crash.
Unfortunately, the crash I see when loading the webarchive (
Attachment 12790
[details]
) looks like
Bug 12467
, so this is probably a "false positive" crash. Once that bug is fixed, you should be able to start trying to reduce the issue again. Also, it appears that the webarchive in
Attachment 12790
[details]
was created by saving from another webarchive file. If you want to convert your original webarchive file into its various pieces, use the WebArchive Folderizer here:
http://homepage.mac.com/gweston/download.html
Or the Web Archive Extractor here:
http://webarchivext.sourceforge.net/
Then you may start reducing the files as plain HTML/CSS/etc.
David Kilzer (:ddkilzer)
Comment 29
2007-01-30 07:15:26 PST
Created
attachment 12791
[details]
Stack trace when loading MijnPostbank.webarchive on ToT This is the same issue as
Bug 12467
.
David Kilzer (:ddkilzer)
Comment 30
2007-01-31 07:09:36 PST
(In reply to
comment #28
)
> Unfortunately, the crash I see when loading the webarchive (
Attachment 12790
[details]
[edit]) > looks like
Bug 12467
, so this is probably a "false positive" crash. Once that > bug is fixed, you should be able to start trying to reduce the issue again.
Hi Bas,
Bug 12467
is now fixed! I would strongly suggest that you take the webarchive of the page that crashes when you enable JavaScript, extract it using one of the tools in
Comment #28
, replace the personal information with "Lorem Ipsum" or similar, then post the files (zipped) to this bug. That way, there will be a lot more people that may look at the problem and it should get fixed a lot faster. As a bonus, you could fix the HTML to reference the local files to make sure the bug is reproduced this way, but it's not necessary (unless no one is able to reproduce the bug with the individual files). If you'd rather not post the cleaned files, please consider sending them privately to Joost or myself for a reduction attempt. Note that
Attachment 12790
[details]
, with
Bug 12467
fixed, prints the following console message when loaded (which may or may not be related): ERROR: called Frame::paint with nil renderer (/path/to/WebKit/WebCore/page/Frame.cpp:1053 void WebCore::Frame::paint(WebCore::GraphicsContext*, const WebCore::IntRect&))
Bas
Comment 31
2007-02-07 06:38:28 PST
Created
attachment 12997
[details]
testcase It took some time to reduce, but I think I have found an issue and a testset. The ZIP file could be unzipped into your /Library/WebServer/Documents surf to
http://localhost/mpb/
then click 'startframes.html' WebKit will crash on you as well. Dragging startpagina.html on it further reduces it to the iframe loaded from 'weboffer/aanbieding.html'. It was difficult to reproduce as the WebArchive Folderizer renamed or did not rename the elements and I had to relink everything to mimic the Postbank with local media. I think it is in this part: <iframe onload="javascript:insertIFrame('webofferdiv', 'weboffer');" id="weboffer" name="weboffer" src="weboffer/aanbieding.html" frameborder="0" scrolling="no" width="100%" height="10" marginwidth="0"></iframe>
Bas
Comment 32
2007-02-07 06:46:13 PST
Created
attachment 12998
[details]
crashlogs of four situations contains the crashlogs in these scenarios: online Postbank webarchive (saved locally with Javascript off) webserver (webarchive disected by tool and on local webserver) startpagina (just the startpagina.html file) They all have the same thread 0 that crashed: 0 com.apple.WebCore 0x013a16d1 WebCore::FrameLoader::completed() + 39 1 com.apple.WebCore 0x010ee57a WebCore::Loader::didFinishLoading(WebCore::SubresourceLoader*) + 422 2 com.apple.WebCore 0x013b1120 WebCore::SubresourceLoader::didFinishLoading() + 50 3 com.apple.WebCore 0x01384f0b -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 53 4 com.apple.Foundation 0x9265ee00 -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 176 5 com.apple.Foundation 0x9265cea5 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 748 6 com.apple.Foundation 0x9265cb41 _sendCallbacks + 201 7 com.apple.CoreFoundation 0x9082afd2 CFRunLoopRunSpecific + 1213 8 com.apple.CoreFoundation 0x9082ab0e CFRunLoopRunInMode + 61 9 com.apple.HIToolbox 0x92ddabef RunCurrentEventLoopInMode + 285 10 com.apple.HIToolbox 0x92dda2fd ReceiveNextEventCommon + 385 11 com.apple.HIToolbox 0x92dda154 BlockUntilNextEventMatchingListInMode + 81 12 com.apple.AppKit 0x9327f465 _DPSNextEvent + 572 13 com.apple.AppKit 0x9327f056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 14 com.apple.Safari 0x00006cea 0x1000 + 23786 15 com.apple.AppKit 0x93278ddb -[NSApplication run] + 512 16 com.apple.AppKit 0x9326cd2f NSApplicationMain + 573 17 com.apple.Safari 0x0005f54a 0x1000 + 386378 18 com.apple.Safari 0x0005f471 0x1000 + 386161
David Kilzer (:ddkilzer)
Comment 33
2007-02-07 07:56:06 PST
(In reply to
comment #31
)
> It took some time to reduce, but I think I have found an issue and a testset.
Great work, Bas!! I am able to reproduce this now (although the stack trace is a bit different with a debug build). That's okay, though. The assertion failure may be catching the bug before it crashes WebKit later.
David Kilzer (:ddkilzer)
Comment 34
2007-02-07 08:00:40 PST
Created
attachment 13006
[details]
Stack trace from debug build This is a stack trace from a debug build loading startpagina.html from
Attachment 12997
[details]
as a file:// URL. (Actually, the first time it loaded it did not crash. I had to reload the page, and it crashed the second time.) It was done using a local debug build of WebKit
r19463
with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). Console output of assertion failure: ASSERTION FAILED: resource->inCache() (/path/to/WebKit/WebCore/loader/Cache.cpp:163 void WebCore::Cache::remove(WebCore::CachedResource*)) Segmentation fault
Alexey Proskuryakov
Comment 35
2007-02-24 07:51:37 PST
I cannot reproduce the crash with the testcase now (perhaps, as a result of the fix for
bug 12479
). Does the site work normally, too?
Bas
Comment 36
2007-02-28 02:59:48 PST
still crashes Host Name: omega Date/Time: 2007-02-28 11:44:08.701 +0100 OS Version: 10.4.8 (Build 8N1051) Report Version: 4 Command: Safari Path: /Applications/Safari.app/Contents/MacOS/Safari Parent: WindowServer [22193] Version: ??? (19879) PID: 25239 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6f432255 Thread 0 Crashed: 0 com.apple.WebCore 0x01351687 WebCore::FrameLoader::completed() + 39 1 com.apple.WebCore 0x010c3b32 WebCore::Loader::didFinishLoading(WebCore::SubresourceLoader*) + 422 2 com.apple.WebCore 0x013617b8 WebCore::SubresourceLoader::didFinishLoading() + 50 3 com.apple.WebCore 0x01336487 -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 53 4 com.apple.Foundation 0x9265ee00 -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 176 5 com.apple.Foundation 0x9265cea5 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 748 6 com.apple.Foundation 0x9265cb41 _sendCallbacks + 201 7 com.apple.CoreFoundation 0x9082afd2 CFRunLoopRunSpecific + 1213 8 com.apple.CoreFoundation 0x9082ab0e CFRunLoopRunInMode + 61 9 com.apple.HIToolbox 0x92ddabef RunCurrentEventLoopInMode + 285 10 com.apple.HIToolbox 0x92dda2fd ReceiveNextEventCommon + 385 11 com.apple.HIToolbox 0x92dda154 BlockUntilNextEventMatchingListInMode + 81 12 com.apple.AppKit 0x9327f465 _DPSNextEvent + 572 13 com.apple.AppKit 0x9327f056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 14 com.apple.Safari 0x00006cea 0x1000 + 23786 15 com.apple.AppKit 0x93278ddb -[NSApplication run] + 512 16 com.apple.AppKit 0x9326cd2f NSApplicationMain + 573 17 com.apple.Safari 0x0005f54a 0x1000 + 386378 18 com.apple.Safari 0x0005f471 0x1000 + 386161
David Kilzer (:ddkilzer)
Comment 37
2007-02-28 06:19:10 PST
(In reply to
comment #36
)
> still crashes
Thanks Bas. Did you reproduce this by logging into the actual site, or did you use one of the attachments on this bug (
Attachment 12997
[details]
or
Attachment 12790
[details]
)?
Bas
Comment 38
2007-03-05 13:54:06 PST
(In reply to
comment #37
)
> (In reply to
comment #36
) > > still crashes > > Thanks Bas. Did you reproduce this by logging into the actual site, or did you > use one of the attachments on this bug (
Attachment 12997
[details]
[edit] or
Attachment 12790
[details]
[edit])? >
The actual site still crashes all the time,
Attachment 12997
[details]
has crashed some times but not all times. I am trying to figure out the scenario to crash it consistently.
Bas
Comment 39
2007-03-05 15:52:21 PST
Created
attachment 13482
[details]
testcase reduced to 2 html files and one dir This is a bug reduction for the "Postbank bug" 9929. It has only two HTML files!!! Now, ehm, please fix it before Leopard, as, uhm, I surely didFinishLoading() ;-) Here is the crash always scenario for my Mac: 1. unzip in /Library/WebServer/Documents 2. activate Personal Webserver 3. Disable all other network intefaces to isolate all to your mac 4. Reset latest WebKit nightly 5. Set homepage to
http://localhost/mpb
6. Quit latest WebKit nightly 7. Launch latest WebKit nightly 8. Click Home button (nightly wants to go to webkit.org) 9. Click 'startpagina.html' 10. Crashes allways with me Thread 0 Crashed: 0 com.apple.WebCore 0x01352443 WebCore::FrameLoader::completed() + 39 1 com.apple.WebCore 0x010c39a2 WebCore::Loader::didFinishLoading(WebCore::SubresourceLoader*) + 422 2 com.apple.WebCore 0x01362716 WebCore::SubresourceLoader::didFinishLoading() + 50 3 com.apple.WebCore 0x01336e7b -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 53 4 com.apple.Foundation 0x9265ee00 -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 176 5 com.apple.Foundation 0x9265cea5 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 748 6 com.apple.Foundation 0x9265cb41 _sendCallbacks + 201 7 com.apple.CoreFoundation 0x9082afd2 CFRunLoopRunSpecific + 1213 8 com.apple.CoreFoundation 0x9082ab0e CFRunLoopRunInMode + 61 9 com.apple.HIToolbox 0x92ddabef RunCurrentEventLoopInMode + 285 10 com.apple.HIToolbox 0x92dda2fd ReceiveNextEventCommon + 385 11 com.apple.HIToolbox 0x92dda154 BlockUntilNextEventMatchingListInMode + 81 12 com.apple.AppKit 0x9327f465 _DPSNextEvent + 572 13 com.apple.AppKit 0x9327f056 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 14 com.apple.Safari 0x00006cea 0x1000 + 23786 15 com.apple.AppKit 0x93278ddb -[NSApplication run] + 512 16 com.apple.AppKit 0x9326cd2f NSApplicationMain + 573 17 com.apple.Safari 0x0005f54a 0x1000 + 386378 18 com.apple.Safari 0x0005f471 0x1000 + 386161
David Kilzer (:ddkilzer)
Comment 40
2007-03-05 21:33:00 PST
(In reply to
comment #39
)
> Created an attachment (id=13482) [edit] > testcase reduced to 2 html files and one dir > > This is a bug reduction for the "Postbank bug" 9929. It has only two HTML > files!!! Now, ehm, please fix it before Leopard, > as, uhm, I surely didFinishLoading() ;-)
Awesome job with the reduction, Bas!! This definitely reproduces a crash on my local debug build of WebKit
r19972
with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). The same steps do not crash shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). Console output with debug build: ASSERTION FAILED: inHeap() == (m_nextFireTime != 0) (/path/to/Projects/Cocoa/WebKit/WebCore/platform/Timer.cpp:212 void WebCore::TimerBase::checkConsistency() const) Segmentation fault Stack trace: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbbadbeef Thread 0 Crashed: 0 com.apple.WebCore 0x016b40cc WebCore::TimerBase::checkConsistency() const + 156 (Timer.cpp:212) 1 com.apple.WebCore 0x01278948 WebCore::TimerBase::setNextFireTime(double) + 332 (Timer.cpp:306) 2 com.apple.WebCore 0x01278b98 WebCore::TimerBase::stop() + 68 (Timer.cpp:181) 3 com.apple.WebCore 0x01278e2c WebCore::TimerBase::~TimerBase [not-in-charge]() + 60 (Timer.cpp:167) 4 com.apple.WebCore 0x016d2d44 WebCore::Timer<WebCore::Element>::~Timer [in-charge deleting]() + 64 (Timer.h:88) 5 com.apple.JavaScriptCore 0x00557090 KJS::JSObject::construct(KJS::ExecState*, KJS::List const&, KJS::Identifier const&, KJS::UString const&, int) + 84 (object.cpp:437) 6 com.apple.WebCore 0x01106e14 WebCore::Document::implicitClose() + 1236 (Document.cpp:1395) 7 com.apple.WebCore 0x01484590 WebCore::FrameLoader::checkEmitLoadEvent() + 596 (FrameLoader.cpp:1118) 8 com.apple.WebCore 0x01490684 WebCore::FrameLoader::checkCompleted() + 468 (FrameLoader.cpp:1089) 9 com.apple.WebCore 0x01491774 WebCore::FrameLoader::loadDone() + 80 (FrameLoader.cpp:1060) 10 com.apple.WebCore 0x011261fc WebCore::DocLoader::setLoadInProgress(bool) + 84 (DocLoader.cpp:182) 11 com.apple.WebCore 0x0112804c WebCore::Loader::didFinishLoading(WebCore::SubresourceLoader*) + 424 (loader.cpp:110) 12 com.apple.WebCore 0x0149d2a0 WebCore::SubresourceLoader::didFinishLoading() + 204 (SubresourceLoader.cpp:191) 13 com.apple.WebCore 0x0149b1ac WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*) + 60 14 com.apple.WebCore 0x01471048 -[WebCoreResourceHandleAsDelegate connectionDidFinishLoading:] + 144 (ResourceHandleMac.mm:370) 15 com.apple.Foundation 0x9299384c -[NSURLConnection(NSURLConnectionInternal) _sendDidFinishLoadingCallback] + 188 16 com.apple.Foundation 0x92991ab8 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 556 17 com.apple.Foundation 0x92991810 _sendCallbacks + 156 18 com.apple.CoreFoundation 0x907dd4cc __CFRunLoopDoSources0 + 384 19 com.apple.CoreFoundation 0x907dc9fc __CFRunLoopRun + 452 20 com.apple.CoreFoundation 0x907dc47c CFRunLoopRunSpecific + 268 21 com.apple.HIToolbox 0x93208740 RunCurrentEventLoopInMode + 264 22 com.apple.HIToolbox 0x93207dd4 ReceiveNextEventCommon + 380 23 com.apple.HIToolbox 0x93207c40 BlockUntilNextEventMatchingListInMode + 96 24 com.apple.AppKit 0x9370cae4 _DPSNextEvent + 384 25 com.apple.AppKit 0x9370c7a8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116 26 com.apple.Safari 0x00006740 0x1000 + 22336 27 com.apple.AppKit 0x93708cec -[NSApplication run] + 472 28 com.apple.AppKit 0x937f987c NSApplicationMain + 452 29 com.apple.Safari 0x0005c77c 0x1000 + 374652 30 com.apple.Safari 0x0005c624 0x1000 + 374308
mitz
Comment 41
2007-03-07 14:48:48 PST
Created
attachment 13531
[details]
Further reduction (will crash) This crashes often (if it does not, reload). The crash results from the FrameView being destroyed as a result of removing the iframe, while a DocLoader still exists whose m_frame pointer points to it. Might be yet another one of those "executing an arbitrary event handler can get this deleted, so this should be protected before and/or checked after the event handler" cases.
mitz
Comment 42
2007-03-07 15:47:14 PST
Created
attachment 13535
[details]
Patch, without change log and regression test
mitz
Comment 43
2007-03-08 05:41:02 PST
Created
attachment 13543
[details]
Patch Fixes the crash and a related issue where the parent document's load event never got dispatched. However, the Safari status bar still remains at "loading".
Darin Adler
Comment 44
2007-03-08 08:53:05 PST
Comment on
attachment 13543
[details]
Patch r=me
David Kilzer (:ddkilzer)
Comment 45
2007-03-08 16:56:52 PST
(In reply to
comment #44
)
> (From update of
attachment 13543
[details]
[edit]) > r=me
Shouldn't the issue with "loading" remaining in the status bar be fixed first? And a manual/automated layout test added?
mitz
Comment 46
2007-03-09 00:14:39 PST
(In reply to
comment #45
)
> (In reply to
comment #44
) > > (From update of
attachment 13543
[details]
[edit] [edit]) > > r=me > > Shouldn't the issue with "loading" remaining in the status bar be fixed first? > And a manual/automated layout test added? >
I just checked, and the "loading" issue exists in TOT and in shipping Safari (not in the crashing case, obviously, but in the case that you remove an iframe before it's finished loading), therefore I think it's a separate bug and shouldn't block landing this patch.
Sam Weinig
Comment 47
2007-03-09 08:19:25 PST
Landed in
r20090
.
Bas
Comment 48
2007-03-12 07:53:17 PDT
I can login to Postbank with 20107 without crashing, great!! But I am not permitted to set VERIFIED.
David Kilzer (:ddkilzer)
Comment 49
2007-03-12 07:58:28 PDT
Verified per
Comment #48
! Thanks for the follow-up testing, Bas!
WebKit bughunter
Comment 50
2008-04-05 01:48:20 PDT
There is a Regression on latest iPod Touch Safari Release 1.1.4 (4A102), it crashes very similar. Unfortunately I was not admitted to iPhone program, so I cannot test it better
mitz
Comment 51
2008-04-05 01:55:35 PDT
(In reply to
comment #50
)
> There is a Regression on latest iPod Touch Safari Release 1.1.4 (4A102), it > crashes very similar. > Unfortunately I was not admitted to iPhone program, so I cannot test it > better
Please use the Apple Bug Reporter at <
http://bugreport.apple.com
> to report iPod Touch issues. Thanks!
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