Bug 9929 - REGRESSION: crash on logging in on mijnpostbank.nl
: REGRESSION: crash on logging in on mijnpostbank.nl
Status: VERIFIED FIXED
Product: WebKit
Classification: Unclassified
Component: Page Loading
: 420+
: Macintosh Mac OS X 10.4
: P1 Critical
Assigned To: mitz@webkit.org
http://www.mijnpostbank.nl
: HasReduction, InRadar, Regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-15 02:09 PDT by Joost de Valk (AlthA)
Modified: 2008-04-05 01:55 PDT (History)
10 users (show)

See Also:


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@webkit.org
no flags Details
Patch, without change log and regression test (1.81 KB, patch)
2007-03-07 15:47 PST, mitz@webkit.org
no flags Details | Formatted Diff | Diff
Patch (9.09 KB, patch)
2007-03-08 05:41 PST, mitz@webkit.org
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joost de Valk (AlthA) 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
Comment 1 Joost de Valk (AlthA) 2006-07-15 02:27:24 PDT
Created attachment 9463 [details]
Crash log
Comment 2 Darin Adler 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.
Comment 3 Martijn Broenland 2006-07-16 03:26:59 PDT
Created attachment 9482 [details]
Crashlog with line numbers

Here's a crash log with line numbers.
Comment 4 Martijn Broenland 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)
Comment 5 Alexey Proskuryakov 2006-07-17 04:15:28 PDT
One more question: does it 
Comment 6 Alexey Proskuryakov 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.
Comment 7 Martijn Broenland 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)
Comment 8 Martijn Broenland 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.
Comment 9 Alice Liu 2006-08-14 14:08:31 PDT
<rdar://problem/4680230>
Comment 10 Alexey Proskuryakov 2006-10-17 09:34:16 PDT
*** Bug 11324 has been marked as a duplicate of this bug. ***
Comment 11 Bas 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
Comment 12 Bas 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.
> 

Comment 13 Alexey Proskuryakov 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.
Comment 14 Martijn Broenland 2006-11-02 12:40:27 PST
r12480 does crash on mijn.postbank.nl (at least, on my powermac here)
Comment 15 Martijn Broenland 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.
Comment 16 Alexey Proskuryakov 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.
Comment 17 Joost de Valk (AlthA) 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 :)
Comment 18 Alexey Proskuryakov 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 ;).
Comment 19 David Kilzer (:ddkilzer) 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?  :)

Comment 20 David Kilzer (:ddkilzer) 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.

Comment 21 David Kilzer (:ddkilzer) 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!
Comment 22 Bas 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




Comment 23 David Kilzer (:ddkilzer) 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.
Comment 24 David Kilzer (:ddkilzer) 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!
Comment 25 Joost de Valk (AlthA) 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 :)
Comment 26 Bas 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
Comment 27 Bas 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.
Comment 28 David Kilzer (:ddkilzer) 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.

Comment 29 David Kilzer (:ddkilzer) 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.
Comment 30 David Kilzer (:ddkilzer) 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&))

Comment 31 Bas 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>
Comment 32 Bas 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
Comment 33 David Kilzer (:ddkilzer) 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.
Comment 34 David Kilzer (:ddkilzer) 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
Comment 35 Alexey Proskuryakov 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?
Comment 36 Bas 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


Comment 37 David Kilzer (:ddkilzer) 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])?

Comment 38 Bas 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. 
Comment 39 Bas 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
Comment 40 David Kilzer (:ddkilzer) 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

Comment 41 mitz@webkit.org 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.
Comment 42 mitz@webkit.org 2007-03-07 15:47:14 PST
Created attachment 13535 [details]
Patch, without change log and regression test
Comment 43 mitz@webkit.org 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".
Comment 44 Darin Adler 2007-03-08 08:53:05 PST
Comment on attachment 13543 [details]
Patch

r=me
Comment 45 David Kilzer (:ddkilzer) 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?

Comment 46 mitz@webkit.org 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.
Comment 47 Sam Weinig 2007-03-09 08:19:25 PST
Landed in r20090.
Comment 48 Bas 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.
Comment 49 David Kilzer (:ddkilzer) 2007-03-12 07:58:28 PDT
Verified per Comment #48!  Thanks for the follow-up testing, Bas!

Comment 50 WebKit bughunter 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
Comment 51 mitz@webkit.org 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!