My best guess is that the value returned by eval is not getting garbage collected.  Assigning to GC component for further investigation/triage.

I'm able to reproduce this issue on Latest Chrome Beta#60.0.3122.66 for 'Win7'.

Able to reproduce this issue(as in crash@console.jpg) on Win-10 using chrome reported version #59.0.3071.115 and latest canary #61.0.3159.0.
Issue is not seen in OS-Mac and OS-Linux.

This is a non-regression issue as it is observed from M50 old builds. In M45 build, the code: (a => {while(((a = (a | 0) + 1 | 0) | 0) !== 0)eval('')})(0) neither returned undefined nor did it crash, rather it showed errors as in the attached screen shot(crash_M45@console.jpg).

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Deleted: crash_M45@console.JPG 156 KB

	crash_M45@console.JPG 156 KB View Download

Deleted: crash@console.JPG 46.1 KB

	crash@console.JPG 46.1 KB View Download

memory sheriffs, PTAL

This is basically a 

while(true) eval('');

with 'a' being context allocated. At the first sight I don't see why we wouldn't run OOM here. 

Adam, any opinion on this one?

I'm skeptical that there's anything actionable here, especially considering that it's an infinite loop (the only way I can imagine this "completing" in firefox is if the user allows the browser to kill the script).

@adamk. My original script is not infinite loop. According to the ES scep, integer overflow is not undefined behavior, so it will iterate exactly 2**32 iterations.

Ah, sorry, I didn't look closely enough at the original test case.

Re: #5, I actually don't know why this should run OOM. Yes, 'a' is context-allocated, but that's only one variable. The eval inside the loop will create a new JSFunction each time through, but I don't see what should be keeping them alive, so this does smell like there could be a GC issue to me.

I just checked locally on my machine. In d8 the script runs actually through in ~12min on my z840 without causing OOM. I assume that the script is killed before completing when executed in Chrome.

I profiled a much shorter run going until 2**28. The GC profile looks fine in the sense that we do not leak. Ideally there wouldn't be any allocations but the garbage that is created is cleaned up afaics.

$ time out/x64.release/d8 --trace-opt --prof script.js 
[marking 0x3e9f9a0c011 <JSFunction a (sfi = 0x3d2c8272cc29)> for optimized recompilation, reason: hot and stable, ICs with typeinfo: 7/7 (100%), generic ICs: 1/7 (14%)]
[compiling method 0x3e9f9a0c011 <JSFunction a (sfi = 0x3d2c8272cc29)> using TurboFan OSR]
[optimizing 0x3e9f9a0c011 <JSFunction a (sfi = 0x3d2c8272cc29)> - took 1.493, 0.647, 0.013 ms]
[marking 0x8bd9a3856e1 <JSFunction (sfi = 0x3d2c8272d3e1)> for optimized recompilation, reason: small function, ICs with typeinfo: 0/0 (100%), generic ICs: 0/0 (0%)]
[compiling method 0x8bd9a385729 <JSFunction (sfi = 0x3d2c8272d3e1)> using TurboFan]
[optimizing 0x8bd9a385729 <JSFunction (sfi = 0x3d2c8272d3e1)> - took 0.053, 0.162, 0.004 ms]
[completed optimizing 0x8bd9a385729 <JSFunction (sfi = 0x3d2c8272d3e1)>]

real	0m45.381s
user	0m51.672s
sys	0m1.800s

As #9 pointed out we do actually allocate JSFunctions which also causes GCs. However, if I interpret the performance profile correctly (profview), we spend quite some time in the runtime.

Top buckets are:
- 11% v8::internal::Runtime_ResolvePossiblyDirectEval
-  9% v8::internal::CompilationCacheTable::LookupEval
-  8% v8::internal::Factory::NewFunctionFromSharedFunctionInfo

I don't think that this is a GC issue.

Aaaand... the logfiles.

Deleted: v8.json 5.3 MB

v8.json 5.3 MB View Download

Deleted: eval-slowness.png 342 KB

	eval-slowness.png 342 KB View Download

+bmeurer

Not sure, but it seems that this may be related to
https://github.com/nodejs/node/issues/21142
and probably
https://github.com/nodejs/node/issues/19733
since the issue appears only when devtools are open. IIUC, the inspector retains a reference to eval'd code in case the user wants to inspect it (see the 4th comment on the second linked issue).