Bug 9929 - REGRESSION: crash on logging in on mijnpostbank.nl
: REGRESSION: crash on logging in on mijnpostbank.nl
Status: VERIFIED FIXED
: WebKit
Page Loading
: 420+
: Macintosh Mac OS X 10.4
: P1 Critical
Assigned To:
: http://www.mijnpostbank.nl
: HasReduction, InRadar, Regression
:
:
  Show dependency treegraph
 
Reported: 2006-07-15 02:09 PST by
Modified: 2008-04-05 01:55 PST (History)


Attachments
Crash log (21.32 KB, text/plain)
2006-07-15 02:27 PST, Joost de Valk (AlthA)
no flags Details
Crashlog with line numbers (23.61 KB, text/plain)
2006-07-16 03:26 PST, Martijn Broenland
no flags Details
Activity window (156.88 KB, image/png)
2006-07-22 00:22 PST, Martijn Broenland
no flags Details
Crashlog 17105 (20.21 KB, text/plain)
2006-10-18 05:37 PST, 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 Review Patch | Details | Formatted Diff | Diff
Patch (9.09 KB, patch)
2007-03-08 05:41 PST, mitz@webkit.org
darin: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-07-15 02:09:41 PST
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 From 2006-07-15 02:27:24 PST -------
Created an attachment (id=9463) [details]
Crash log
------- Comment #2 From 2006-07-15 06:26:53 PST -------
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 From 2006-07-16 03:26:59 PST -------
Created an attachment (id=9482) [details]
Crashlog with line numbers

Here's a crash log with line numbers.
------- Comment #4 From 2006-07-16 03:30:30 PST -------
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 From 2006-07-17 04:15:28 PST -------
One more question: does it 
------- Comment #6 From 2006-07-17 04:20:47 PST -------
Sorry - was going to ask whether removing SafariStand helps, but then noticed that the first crash log is clean.
------- Comment #7 From 2006-07-22 00:19:54 PST -------
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 From 2006-07-22 00:22:49 PST -------
Created an attachment (id=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 From 2006-08-14 14:08:31 PST -------
<rdar://problem/4680230>
------- Comment #10 From 2006-10-17 09:34:16 PST -------
*** Bug 11324 has been marked as a duplicate of this bug. ***
------- Comment #11 From 2006-10-18 05:37:50 PST -------
Created an attachment (id=11133) [details]
Crashlog 17105

I crashed WebKir as well on login to http://mijn.postbank.nl
------- Comment #12 From 2006-10-24 15:27:51 PST -------

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 From 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 From 2006-11-02 12:40:27 PST -------
r12480 does crash on mijn.postbank.nl (at least, on my powermac here)
------- Comment #15 From 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 From 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 From 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 From 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 From 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 From 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 From 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 From 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 From 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 From 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 From 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 From 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 From 2007-01-30 05:48:01 PST -------
Created an attachment (id=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 From 2007-01-30 07:14:11 PST -------
(In reply to comment #27)
> Created an attachment (id=12790) [edit] [details]
> 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 From 2007-01-30 07:15:26 PST -------
Created an attachment (id=12791) [details]
Stack trace when loading MijnPostbank.webarchive on ToT

This is the same issue as Bug 12467.
------- Comment #30 From 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 From 2007-02-07 06:38:28 PST -------
Created an attachment (id=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 From 2007-02-07 06:46:13 PST -------
Created an attachment (id=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 From 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 From 2007-02-07 08:00:40 PST -------
Created an attachment (id=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 From 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 From 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 From 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 From 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 From 2007-03-05 15:52:21 PST -------
Created an attachment (id=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 From 2007-03-05 21:33:00 PST -------
(In reply to comment #39)
> Created an attachment (id=13482) [edit] [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() ;-)

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 From 2007-03-07 14:48:48 PST -------
Created an attachment (id=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 From 2007-03-07 15:47:14 PST -------
Created an attachment (id=13535) [details]
Patch, without change log and regression test
------- Comment #43 From 2007-03-08 05:41:02 PST -------
Created an attachment (id=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 From 2007-03-08 08:53:05 PST -------
(From update of attachment 13543 [details])
r=me
------- Comment #45 From 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 From 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 From 2007-03-09 08:19:25 PST -------
Landed in r20090.
------- Comment #48 From 2007-03-12 07:53:17 PST -------
I can login to Postbank with 20107 without crashing, great!!
But I am not permitted to set VERIFIED.
------- Comment #49 From 2007-03-12 07:58:28 PST -------
Verified per Comment #48!  Thanks for the follow-up testing, Bas!
------- Comment #50 From 2008-04-05 01:48:20 PST -------
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 From 2008-04-05 01:55:35 PST -------
(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!