1031228 - Base64 encoded images blocked by the popup blocker causes large memory usage on Windows

Status: RESOLVED INCOMPLETE

(Core :: JavaScript: GC, defect)

Description

[gmonster]

Attachment: Scratchpad example

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140616143923

Steps to reproduce:

1. Copy the contents http://pastebin.com/2mQMfCkB into Scratchpad - this repeatedly opens a ~300 kb base64 encoded image
2. Ensure that popups aren't automatically opened. 
3. Execute the Scratchpad with Ctrl-R
4. Wait. 

It has been at least a few versions of Firefox since I first noticed the issue. 


Actual results:

On Windows, with Task Manager open you can see the memory ballooning, and in a few seconds, Firefox simply crashes when it reaches ~3GB of memory. Also, note that the popups need to be blocked, so if you run the Scratchpad on about:home or similar page, they will open normally - still using a good deal of memory, but not crashing. This was all tested with no addons enabled. 

On a machine running Linux I used, memory doesn't balloon anywhere near as much. Changing the number of times the image is opened from 100 to more than 5000 is possible, without reaching the memory limit. 


Expected results:

The amount of memory used by my Linux machine seems fairly reasonable per image. Windows appeared to be off by more than a factor of 10. I would've expected them to be at least somewhat comparable and Windows not to have run out of memory so quickly.

Comment 1

[Timothy Nikkel (:tnikkel)]

Seems to be just as bad on Windows as for Mac for me, except we have lots of address space on mac so it doesn't crash. Instead it peaks and then returns to a reasonable level. I managed to get an about:memory report while it was high, almost all of the memory was heap-unclassified. It might be tricky to get a dmd report when the memory usage is high though.

Comment 2

[Timothy Nikkel (:tnikkel)]

This dmd output shows where nearly all of it comes from (next record is responsible for 27mb)

Unreported: 73 blocks in stack trace record 1 of 2,326
 2,882,072,576 bytes (2,881,922,032 requested / 150,544 slop)
 92.08% of the heap (92.08% cumulative);  98.25% of unreported (98.25% cumulative)
 Allocated at
   replace_malloc[/Users/tim/ffdmd/src/obj-dbg/dist/lib/libdmd.dylib +0x310F] 0xb10f
   malloc_zone_malloc[/usr/lib/system/libsystem_c.dylib +0x2D183] 0x88277183
   malloc[/usr/lib/system/libsystem_c.dylib +0x2DBD7] 0x88277bd7
   JSAutoStructuredCloneBuffer::copy(unsigned long long const*, unsigned long, unsigned int)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x327249C] 0x578049c
   nsSameProcessAsyncMessageBase::nsSameProcessAsyncMessageBase(JSContext*, nsAString_internal const&, mozilla::dom::StructuredCloneData const&, JS::Handle<JSObject*>, nsIPrincipal*)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x197F515] 0x3e8d515
   nsInProcessTabChildGlobal::DoSendAsyncMessage(JSContext*, nsAString_internal const&, mozilla::dom::StructuredCloneData const&, JS::Handle<JSObject*>, nsIPrincipal*)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x199FC5C] 0x3eadc5c
   non-virtual thunk to nsInProcessTabChildGlobal::DoSendAsyncMessage(JSContext*, nsAString_internal const&, mozilla::dom::StructuredCloneData const&, JS::Handle<JSObject*>, nsIPrincipal*)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x199FD30] 0x3eadd30
   nsFrameMessageManager::DispatchAsyncMessageInternal(JSContext*, nsAString_internal const&, mozilla::dom::StructuredCloneData const&, JS::Handle<JSObject*>, nsIPrincipal*)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x197A24E] 0x3e8824e
   nsFrameMessageManager::DispatchAsyncMessage(nsAString_internal const&, JS::Value const&, JS::Value const&, nsIPrincipal*, JSContext*, unsigned char)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x197A446] 0x3e88446
   NS_InvokeByIndex[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0xC838D] 0x25d638d
   CallMethodHelper::Call()[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x13A45F2] 0x38b25f2
   XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x138C72B] 0x389a72b
   XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)[/Users/tim/ffdmd/src/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/./XUL +0x138E514] 0x389c514

Comment 3

[Nicholas Nethercote [inactive]]

Structured cloning... that suggests that we're copying enormous amounts of data to or from a worker. sfink, what do you think?

Comment 4

[Steve Fink [:sfink] [:s:]]

This sounds similar to bug 1037358. Most of that has been resolved now. Does this bug still reproduce?

Comment 5

[Timothy Nikkel (:tnikkel)]

With a build from today it reproduces the same as before, with the same dmd blame.

Comment 6

[Kanchan Kumari QA]

Hello Reporter, I tried to duplicate this issue on a Win 7 x64 virtual machine (2 GB of RAM) with the latest released version of Firefox 43.0.4 and it seems that the issue stands fixed now. Before running this script on scratchpad, firefox was using about ~188 MB of memory. As soon as I executed the script, memory shot up to almost ~1.6 GB within a few seconds. However, after a few seconds, it dropped and settled around ~400 MB. I did not see any crash either.

Name 	Firefox
Version 	43.0.4
Build ID 	20160105164030
Update Channel 	release
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0

If you have not upgraded your firefox as of yet, can you please double check and let us know your findings.

Comment 7

[Kanchan Kumari QA]

Hello Reporter, I just wanted to update you that I saw a very similar behavior on Ubuntu 32 bit as well.

Comment 8

[André Bargull [:anba]]

Probably fixed per comment #6, but since there was no response from reporter closing as INCOMPLETE.