Intern 4.4.0 is causing OOM Node errors when running Firefox

[vladikoff]

Expected behavior

Tests should run

Current behavior

Running functional tests targeting Firefox causes OOM Node error.

Possible solution

When browser is switched to Chrome then the problem goes away. We had this happen in 2 different projects. See webcompat/webcompat.com#2764

Steps to reproduce (for bugs)

I am gonna see if I can produce a simplified example once I have time

Environment

Intern version: 4.4.0
Node version: 8
NPM version: 3
Browser version: Firefox 58 or 64, etc

Additional information

Some info one of our engineers discovered, not sure if relevant:

about this test-that-eats-all-heap. If this is a hint, on the teamcity host with an strace, I see this error: "stacktrace": \"org.openqa.selenium.UnsupportedCommandException: GET \\u002fsession\\u002fbb421c88-f07f-4dce-bca5-4a74b384adf9\\u002fwindow

Crash on a Mac after ~3 minutes:

Creating Firefox profile...
Listening on localhost:9090 (ws 9077)
Tunnel started

<--- Last few GCs --->

[4148:0x103000000]   384503 ms: Mark-sweep 1174.2 (1541.4) -> 1174.2 (1541.4) MB, 769.2 / 0.0 ms  allocation failure GC in old space requested
[4148:0x103000000]   385609 ms: Mark-sweep 1174.2 (1541.4) -> 1174.2 (1532.4) MB, 986.3 / 0.0 ms  last resort GC in old space requested
[4148:0x103000000]   386545 ms: Mark-sweep 1174.2 (1532.4) -> 1174.2 (1523.4) MB, 935.5 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x35e4da4a58b9 <JSObject>
    2: lookup(aka lookup) [dns.js:154] [bytecode=0x35e4c0438849

CI Log:

Listening on localhost:9090 (ws 9077)
Tunnel started

<--- Last few GCs --->

[123:0x2331220]    99637 ms: Mark-sweep 1058.3 (1499.4) -> 1058.2 (1500.4) MB, 875.2 / 0.0 ms  allocation failure GC in old space requested
[123:0x2331220]   100488 ms: Mark-sweep 1058.2 (1500.4) -> 1058.2 (1456.9) MB, 850.4 / 0.0 ms  last resort GC in old space requested
[123:0x2331220]   101296 ms: Mark-sweep 1058.2 (1456.9) -> 1058.2 (1445.9) MB, 807.7 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x12b6ea8258b9 <JSObject>
    1: onread [net.js:~583] [pc=0x109dabb92a94](this=0x1c25a5338971 <TCP map = 0x11c13af75ab1>,nread=3752,buffer=0x1c25a5339bd9 <Uint8Array map = 0x11c13af6dff9>)
    2: arguments adaptor frame: 3->2

==== Details ================================================

[1]: onread [net.js:~583] [pc=0x109dabb92a94](this=0x1c25a5338971 <TCP map = 0x11c13af75ab1>,nread=3752,buffer=0x1c25a5339bd9 <Uint8Ar...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x8ccf9c [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewCode(v8::internal::CodeDesc const&, unsigned int, v8::internal::Handle<v8::internal::Object>, bool, int) [node]
 6: v8::internal::CodeGenerator::MakeCodeEpilogue(v8::internal::TurboAssembler*, v8::internal::EhFrameWriter*, v8::internal::CompilationInfo*, v8::internal::Handle<v8::internal::Object>) [node]
 7: v8::internal::compiler::CodeGenerator::FinalizeCode() [node]
 8: v8::internal::compiler::PipelineImpl::FinalizeCode() [node]
 9: v8::internal::compiler::PipelineCompilationJob::FinalizeJobImpl() [node]
10: v8::internal::Compiler::FinalizeCompilationJob(v8::internal::CompilationJob*) [node]
11: v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() [node]
12: v8::internal::StackGuard::HandleInterrupts() [node]
13: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) [node]
14: 0x109dab9042fd
Aborted

It seems the browser just hangs and tries to do something:

[jason0x43]

Hmmm...well that's annoying. The self tests for 4.4.0 passed last week, both locally and on Travis, but today FF (64.0.2) is hanging for me. 4.3.3 and 4.3.4 appear to be working properly.

[jason0x43]

From a quick test, it looks like the issue may be with Leadfoot. Downgrading leadfoot to 2.2.3 seems to resolve the issue.

[vladikoff]

@jason0x43 I had a hunch that was it too! Thank you for looking into it!

[jason0x43]

The issue is corrected in Leadfoot 2.2.5. I published Intern 4.4.1 to ensure the updated Leadfoot is picked up in new installs.