Core dump after huge hang on relatively small cast

[strazto]

When attempting to convert a relatively small cast demo.cast.txt, I got this:

Stack trace

``` svg-term --in demo.cast --out demo.svg --width=104 --height=82 <--- Last few GCs ---> [55408:0x55a83c1e3250] 996781 ms: Mark-sweep 1560.5 (2027.7) -> 1560.4 (1965.7) MB, 1398.6 / 0.3 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1540 ms) last resort GC in old space requested [55408:0x55a83c1e3250] 998192 ms: Mark-sweep 1560.4 (1965.7) -> 1560.4 (1943.2) MB, 1410.8 / 0.0 ms last resort GC in old space requested <--- JS stacktrace ---> ==== JS stack trace ========================================= Security context: 0xf3856698fe1 0: builtin exit frame: freeze(this=0xf3856698229 ,0x359fe6bffd31

[strazto]

I find that it works reliably if I always convert using --cast with asciinema's UUID, so for now, it's okay to just upload them and use that

[pdevine]

I just ran into the same thing. Have 32 GB of RAM, but it seems like it's complaining about being out of heap memory with the error: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

[Accacio]

Same here:

 <--- Last few GCs --->

[3566:0x55b8e2ce9260]   686477 ms: Mark-sweep 1837.5 (2382.2) -> 1837.4 (2329.2) MB, 1164.4 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1165 ms) last resort GC in old space requested
[3566:0x55b8e2ce9260]   687668 ms: Mark-sweep 1837.4 (2329.2) -> 1837.4 (2309.7) MB, 1191.2 / 0.1 ms  last resort GC in old space requested

<--- JS stacktrace --->

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

Security context: 0x2da95dc18fe1 <JSObject>
    1: new constructor [/usr/local/lib/node_modules/svg-term-cli/node_modules/load-asciicast/index.js:~901] [pc=0x17132b1f0ffd](this=0x104482b2f959 <JSObject>,a=0x2da95dc02211 <null>,b=0x2c29369ce439 <String[13]: new-line-mode>,c=0x2c29369ce439 <String[13]: new-line-mode>,d=1467504785)
    4: cljs$core$IAssociative$_assoc$arity$3 [/usr/local/lib/node_modules/svg-term-cli/node_modules/load-asciic...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [svg-term]
 2: 0x55b8e147e011 [svg-term]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [svg-term]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [svg-term]
 5: v8::internal::Factory::NewCode(v8::internal::CodeDesc const&, unsigned int, v8::internal::Handle<v8::internal::Object>, bool, int) [svg-term]
 6: v8::internal::CodeGenerator::MakeCodeEpilogue(v8::internal::TurboAssembler*, v8::internal::EhFrameWriter*, v8::internal::CompilationInfo*, v8::internal::Handle<v8::internal::Object>) [svg-term]
 7: v8::internal::compiler::CodeGenerator::FinalizeCode() [svg-term]
 8: v8::internal::compiler::PipelineImpl::FinalizeCode() [svg-term]
 9: v8::internal::compiler::PipelineCompilationJob::FinalizeJobImpl() [svg-term]
10: v8::internal::CompilationJob::FinalizeJob() [svg-term]
11: v8::internal::Compiler::FinalizeCompilationJob(v8::internal::CompilationJob*) [svg-term]
12: v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() [svg-term]
13: v8::internal::StackGuard::HandleInterrupts() [svg-term]
14: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) [svg-term]
15: 0x17132b0840bd
[1]    3566 abort (core dumped)  svg-term --cast 375764 --out controlled.svg --width=80 --height=25

[pdevine]

I noticed I was able to work around this by using OSX instead of Linux on the exact same asciinema cast. I tried changing the heap size in Linux but still ran into the same problem.