Unable to reproduce the issue on Ubuntu 14.04, Win-10 and mac 10.12.6 using chrome stable #62.0.3202.75 and latest dev #64.0.3253.3

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Opened the URL: http://downdetector.com/status/level3/map/
2. Waited for a minute.
3. Observed that the page loaded without any issues.

nharper@ - Could you please check the issue on latest dev #64.0.3253.3 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!
		

Deleted: 781980.ogv 14.7 MB

	781980.ogv 14.7 MB View Download

Attached is a video of it reproducing on 64.0.3253.3 in a fresh profile.

Deleted: IMG-1052.MOV 11.6 MB

IMG-1052.MOV 11.6 MB Download

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue on Ubuntu 14.04 trusty using chrome latest dev #64.0.3260.2 and latest beta #63.0.3239.30.

Following are the steps followed to reproduce the issue.
------------
1. Created an empty folder and launched chrome browser using the command google-chrome-unstable --user-data-dir=/home/krajshree/Desktop/var http://downdetector.com/status/level3/map/
2. Observed that the page loaded without any issues.

Could anyone from Blink>JavaScript team please help us in triaging the issue as the issue is not reproducible from TE-end. Hence, removing the Needs-Bisect label. Please feel free to add the same if required.

Thanks...!!

Could some one from Blink>JavaScript team please look in to this issue.

Thank you!

Adding this week's memory sheriffs for investigation.

I got the Oh Snap right on visiting the page, wow.
Building chrome to investigate.

I see the call to sysconf(pages_name) in AmountOfMemory() (sys_info_linux.cc:27) returns -1, which isn't expected.

There is an old bug and CL where it's pointed out that some versions of linux can't correctly return information in this function.

Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=472701
     "sys_info_linux.cc:AmountOfMemory uses non-standard sysconf values" 
CL: https://codereview.chromium.org/1050233002/ (to fix it).

Callstack attached...

Deleted: CallStack.png 100 KB

	CallStack.png 100 KB View Download

Hi Stephen,
This bug is an instance of crbug.com/472701, for which you made a fix CL in the past. Maybe you should land that. I'll send it over to you as it's not in the V8 code. Thanks!

Sorry about that, the *main issue* here is likely an interaction between the sandbox and a large allocation on the web page. I will keep the investigation assigned to me for now while diagnosing.

Hi Eric, we found an interaction between the sandbox and starting chrome with this webpage. If you have the feature WebAssemblyTrapHandler on, then you'll get the crash described (ignore the side issue in the comments above about AmountOfMemory()).

In sandbox_linux.cc, there is special code to limit address_space_limit_max to 4 terabytes if the wasm trap handler is enabled. Unfortunately it is not enough.

Can you address?

I don't think this is related to trap handlers. I just built master and got a crash both with and without trap handlers. I added logging in the routine the allocates Wasm buffers and this logging did not run, so it seems the page is not using Wasm.

Bill, is there any chance your memory allocation changes are related? It looks like this started in 62, which is probably too early for your changes.

Yes, M62 branched on 8/31 which is well before my changes to base/platform. I had made some changes in allocation.cc, as well as adding a OnCriticalMemoryPressure handler to the v8::Platform API. This was to make it possible to reserve address space on Win32 systems. That wouldn't be happening on Linux of course.

I'm getting what looks like the same behavior (I haven't dug into it, but I see v8::internal::V8::FatalProcessOutOfMemory in the stacktrace) when visiting http://sftransitriders.org/lrv4/. (I just tested on a debug build of tip of tree at 80a699904010b720a7065c18e43b5552e5719de5 (near 65.0.3296.0).)

I noticed that both of the pages where this happens have some sort of custom google map embedded in them - I don't know if that's useful information for this bug.

I didn't look closely enough at that last link - it has an openstreetmap map, not google maps.