Too large plugins are crashing. Test case: <html> <object width="9999999999" data="test.swf"></object> </html>
Created attachment 243629 [details] proposed fix
Comment on attachment 243629 [details] proposed fix Patch looks good, but the test needs to use the test plug-in.
(In reply to comment #2) > Comment on attachment 243629 [details] > proposed fix > > Patch looks good, but the test needs to use the test plug-in. Do you mean x-webkit-test-netscape? I tried it but this only happens with x-shockwave-flash. I can change it to <embed width="9999999999" src="foo.swf" type="application/x-shockwave-flash"> if you prefer that.
(In reply to comment #3) > (In reply to comment #2) > > Comment on attachment 243629 [details] > > proposed fix > > > > Patch looks good, but the test needs to use the test plug-in. > > Do you mean x-webkit-test-netscape? I tried it but this only happens with > x-shockwave-flash. > I can change it to > <embed width="9999999999" src="foo.swf" type="application/x-shockwave-flash"> > if you prefer that. My point is that we can't have tests that rely on Flash, because then we'd require people to install Flash. Maybe we can make the test plug-in crash somehow?
Created attachment 243826 [details] proposed fix 2 This way its crashing with the test plug-in.
Comment on attachment 243826 [details] proposed fix 2 Clearing flags on attachment: 243826 Committed r177824: <http://trac.webkit.org/changeset/177824>
All reviewed patches have been landed. Closing bug.
The new test crashes on Mac with a RELEASE_ASSERT: https://build.webkit.org/results/Apple%20Yosemite%20Release%20WK2%20(Tests)/r177825%20(1624)/plugins/large-plugin-crash-crash-log.txt Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.JavaScriptCore 0x000000010867bc32 bmalloc::Heap::allocateXLarge(std::__1::lock_guard<bmalloc::StaticMutex>&, unsigned long) + 98 1 com.apple.JavaScriptCore 0x000000010867a7e7 bmalloc::Allocator::allocateXLarge(unsigned long) + 71 2 com.apple.JavaScriptCore 0x000000010865a537 WTF::fastMalloc(unsigned long) + 151 3 com.apple.JavaScriptCore 0x000000010865a5b1 WTF::tryFastMalloc(unsigned long) + 17 EWS did see the problem, but the patch got landed before the bubble turned red. What's the next step here, should the patch be rolled out?
It's making bots way too red, and it's the only test for this fix, so skipping is not really appropriate. Rolling out.
Now thats a problem on Gtk as well after enabling bmalloc. PassRefPtr<ShareableBitmap> ShareableBitmap::create(const IntSize& size, Flags flags) using tryFastMalloc to allocate memory but it seems if it can't allocate enough memory it will just crash instead of returning with null. I think we should implement the tryFastMalloc correctly or if we don't want to support this then rename it and clear the return value checks to prevent confusion.
So, we need to fixes to address this bug: 1. the fix to PluginProxy::updateBackingStore(), 2. and a fix to bmalloc to have tryFastMalloc actually work.
<rdar://problem/19846625>
Attached patch was updated "PluginProxy.cpp" file, which is now removed from Webkit source (checked on Github), it was removed in following commit: https://github.com/WebKit/WebKit/commit/043ef2367e62a2cc7e9facb1bdc42b0867b8dd6d Is this applicable now? or this can be marked as "RESOLVED WONTFIX"? Thanks!