New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 697192 link

Starred by 4 users

Issue metadata

Status: Archived
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

postMessage between IFrame and parent eventually crashes with runs out of memory

Reported by s-weathe...@live.com, Feb 28 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. Create two HTML files:

	a.html:

	<html>
	<button onclick="sendMessagesToFrame()">Start sending messages to IFrame</button>
	<iframe id="iframe" src="b.html"></iframe>

	<script>
	        var i = 0;
	        function sendMessagesToFrame() {
	            ++i;
	            var message = Array(1000 * 1000 * 10).join("0123456789");
	            window.parent.postMessage(message, "*");
	            console.log(i);
	            setTimeout(sendMessagesToFrame, 1000);
	        }
	     </script>

	</html>

	b.html:

<html>
IFrame

<button onclick="sendMessagesToParent()">Start sending messages to parent</button>

    <script>
        var i = 0;
        function sendMessagesToParent() {
            ++i;
            var message = Array(1000 * 1000 * 10).join("0123456789");
            window.parent.postMessage(message, "*");
            console.log(i);
            setTimeout(sendMessagesToParent, 1000);
        }
    </script>

</html>

2. Open a.html in Chrome
3. Click on either the "Start sending messages to IFrame" or "Start sending messages to parent" button (they both crash)
4. Watch the memory usage

What is the expected behavior?

What went wrong?
Memory usage continually grows (within 30s to about 3GB), and eventually crashes with out of memory.

Did this work before? N/A 

Chrome version: 56.0.2924.87 (64-bit)  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

Note that forcing a GC causes the memory to decline. But unless a GC occurs, a crash is inevitable.

This is causing crashes with an electron app of ours where we make heavy use of messages between frames.

 

Comment 1 by woxxom@gmail.com, Feb 28 2017

Hmm, currently 128MiB is the hardcoded limit [1] for message size and you're sending 100MB messages. This hardcore use case of sending close-to-maximum-size messages every second might be unaccounted for, meaning you might have found a DoS possibility.

  [1]: https://chromium.googlesource.com/chromium/src/+/a09b9be79387f1107ba29c5f7b0051168193d958/ipc/ipc_channel.h#92
Correction, a.html should be:

<html>
<button onclick="sendMessagesToFrame()">Start sending messages to IFrame</button>
<iframe id="iframe" src="b.html"></iframe>

<script>
    var frame = document.getElementById("iframe");

        var i = 0;
        function sendMessagesToFrame() {
            ++i;
            var message = Array(1000 * 1000 * 10).join("0123456789");
            frame.contentWindow.postMessage(message, "*");
            console.log(i);
            setTimeout(sendMessagesToFrame, 1000);
        }
     </script>

</html>

I'm not sure if the messages have to be that large for issues, but it's easier to repro that way.  We've been seeing inconsistent results, maybe related to how close to the max heap size/machine memory we're at?
Cc: kavvaru@chromium.org
Components: Blink>HTML>IFrame
Labels: -Type-Bug -Pri-2 M-58 Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.3 using chrome version  56.0.2924.87 and canary 58.0.3025.5.
This is regression issue broken in M51.Please find the bisect information as below

Narrow Bisect::
Good :: 51.0.2674.0  ---  (build revision 380495)
Bad:: 51.0.2675.0   ---  (build revision 380818)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/6b84474a3a718e09d19280edfa6065564b249ea6..ccb033d86c3371aa90b079b7bac879fd536e02ad

Unable to find the suspect from the change log.
Could any one from blink team please look into this issue.

Thanks,

Comment 5 by woxxom@gmail.com, Mar 1 2017

kavvaru@, the CL range you've found contains more snapshots so it's possible to narrow it down:

380602 (good) - 380608 (bad)
https://chromium.googlesource.com/chromium/src/+log/52643c06..c4ee1b31?pretty=fuller
Suspecting r380607 "Add threshold for V8Followup-IdleGC"
It's the only CL related to garbage collection.
Components: -Blink

Comment 7 by kochi@chromium.org, Mar 16 2017

Components: -Blink>HTML>IFrame Blink>MemoryAllocator>GarbageCollection
Forwarding to GarbageCollection component, per comment#5.
I think this is nothing specific to <iframe>.

Comment 8 by sigbjo...@opera.com, Mar 16 2017

Components: Blink>Messaging
A "memory pressure GC" isn't forced by ThreadState::shouldForceMemoryPressureGC(), as the calculated growth rate for PartitionAlloc isn't above the required 1.5 for that to happen.

The use of estimatedLiveSize() in ThreadState::partitionAllocGrowingRate() looks unexpected -- if there's a large gap between the PA size at last GC and the current one, a growth factor computed as (current / (current - last)) will be lower than expected/wanted. Perhaps we should use a different growth factor calculation when checking for mem-pressure GCs?
Status: Archived (was: Untriaged)
The GCs involved (V8 and Oilpan) changed a lot since back then. Please reopen if this is still a problem.

Sign in to add a comment