Bug 9929 – REGRESSION: crash on logging in on mijnpostbank.nl

• Component: Page Loading
• Status: VERIFIED FIXED

[Joost de Valk (AlthA)]

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

[Joost de Valk (AlthA)]

Created attachment 9463 [details]
Crash log

[Darin Adler]

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]

Created attachment 9482 [details]
Crashlog with line numbers

Here's a crash log with line numbers.

[Martijn Broenland]

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]

One more question: does it 

[Alexey Proskuryakov]

Sorry - was going to ask whether removing SafariStand helps, but then noticed that the first crash log is clean.

[Martijn Broenland]

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]

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]

<rdar://problem/4680230>

[Alexey Proskuryakov]

*** Bug 11324 has been marked as a duplicate of this bug. ***

[Bas]

Created attachment 11133 [details]
Crashlog 17105

I crashed WebKir as well on login to http://mijn.postbank.nl

[Bas]

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]

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]

r12480 does crash on mijn.postbank.nl (at least, on my powermac here)

[Martijn Broenland]

It appears to be somewhere between 12306 and 12317 here.
12306 works
12317 crashes

Confirmed it on several other computers.

[Alexey Proskuryakov]

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)]

If there were such a thing as a P0, this bug would be in the category, so, ehm, please fix :)

[Alexey Proskuryakov]

(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)]

Joost, what's the minimum account balance to open an account?  Can we start a WebKit fund for such things?  :)

[David Kilzer (:ddkilzer)]

(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)]

(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]

(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)]

(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)]

(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)]

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]

(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]

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)]

(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)]

Created attachment 12791 [details]
Stack trace when loading MijnPostbank.webarchive on ToT

This is the same issue as Bug 12467.

[David Kilzer (:ddkilzer)]

(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]

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]

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)]

(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)]

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]

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]

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)]

(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]

(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]

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)]

(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

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.

Created attachment 13535 [details]
Patch, without change log and regression test

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 on attachment 13543 [details]
Patch

r=me

[David Kilzer (:ddkilzer)]

(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?

(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]

Landed in r20090.

[Bas]

I can login to Postbank with 20107 without crashing, great!!
But I am not permitted to set VERIFIED.

[David Kilzer (:ddkilzer)]

Verified per Comment #48!  Thanks for the follow-up testing, Bas!

[WebKit bughunter]

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

(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!