Using the latest Windows nightly (WebKit-r60066) and the following basic DHTML page, I observe either a crash or an application failure after anywhere from 100-700 reloads (progressions): <html> <head> <title>Test</title> <script type="text/javascript"> var num_progressions = 0; const max_progressions = 100000; function on_doc_load() { var el = document.getElementById("m_holder").addEventListener("load",on_image_received); on_image_received(); } function on_image_received( i_event ) { num_progressions++; document.getElementById("display").innerHTML = num_progressions; if (num_progressions < max_progressions) document.getElementById("m_holder").src = "test.jpg?time=" + (new Date().getTime()) + "&rand=" + (Math.round(Math.random()*10000)/10000) } </script> </head> <body onload="on_doc_load()" style="margin:0; padding:0; display:block;"> <div id="div_holder"> <div id="div_render"> <img width="100%" height="100%" id="m_holder"/> <br /> </div> <div id="display" style="position:absolute; right:15px; bottom:15px; color:#777777; display:block;"></div> </div> </body> </html> Tested using HTTP only. The page essentially just reloads the same "test.jpg" image over and over. Note that you need to supply your own "test.jpg" in the same directory as this file and generally larger files cause the bug behavior to show up sooner (in my tests). I used the one here: http://farm4.static.flickr.com/3415/3245411639_f4a01b96b7_o.jpg (Credit: http://www.flickr.com/photos/gcmenezes/3245411639/sizes/l/ )
On Mac OS X, I'm seeing rapid memory growth, so I suspect that the crash is caused by an out of memory condition. Could you please attach a crash log to confirm, as described in <http://webkit.org/quality/crashlogs.html>? Also, are you seeing memory growth in Windows process monitor?
I'm seeing the same memory growth with shipping Safari 4.0.5 on Mac OS X as I do with r60082 nightly.
(In reply to comment #1) > On Mac OS X, I'm seeing rapid memory growth, so I suspect that the crash is caused by an out of memory condition. > > Could you please attach a crash log to confirm, as described in <http://webkit.org/quality/crashlogs.html>? Also, are you seeing memory growth in Windows process monitor? Thanks Alexey for your attentiveness to the matter. I can confirm that the memory growth is continual until the crash, according to the Windows process monitor. I figured the issue was memory related, so I apologize for not including this tidbit in the bug report. The only crash report I can provide right now is that from the Windows crash dialog: Problem signature: Problem Event Name: APPCRASH Application Name: Safari.exe Application Version: 5.31.22.7 Application Timestamp: 4b8f94fa Fault Module Name: ntdll.dll Fault Module Version: 6.0.6002.18005 Fault Module Timestamp: 49e03824 Exception Code: 80000003 Exception Offset: 00010004 OS Version: 6.0.6002.2.2.0.256.1 Locale ID: 1033 Additional Information 1: fd00 Additional Information 2: ea6f5fe8924aaa756324d57f87834160 Additional Information 3: fd00 Additional Information 4: ea6f5fe8924aaa756324d57f87834160 It's outside of my scoped effort on this bug to reconfigure my workstation and reboot the machine. Sorry. I hope the above helps. If you'd like me to provide the dissassembly where the crash happens, I am willing to do that. I did not build Webkit from source for this bug. (In reply to comment #2) > I'm seeing the same memory growth with shipping Safari 4.0.5 on Mac OS X as I do with r60082 nightly. Yes, I concur. In fact, I first observed the behavior in the shipping Mobile Safari on the iPad, and have since observed it in all Webkit based browsers I use -- Chrome, and Desktop Safari). The issue is least pronounced on Desktop Safari, but as you note it is still present. Thanks again for the prompt attention.
<rdar://problem/8025930>
See also: bug 31253