Out of heap space crash

[bashrc2]

After roughly a 24-48 hours it will always crash with a javascript out of heap space error (memory leak). This is with one cabal open (the default one) and not much activity.

It's been happening for the last few versions (at least). Fixing this ought to be the top priority, even if it's something in an upstream library.

[rinchen]

I continue to get this as well.

<--- Last few GCs --->

[22306:0x450ea20] 658478185 ms: Mark-sweep 988.0 (1000.3) -> 988.0 (1000.3) MB, 1677.1 / 0.0 ms (average mu = 0.444, current mu = 0.102) last resort GC in old space requested
[22306:0x450ea20] 658480065 ms: Mark-sweep 988.0 (1000.3) -> 988.0 (1000.3) MB, 1879.9 / 0.0 ms (average mu = 0.274, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

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

0: ExitFrame [pc: 0x13c5b79]
1: StubFrame [pc: 0x1421b79]

Security context: 0x292556dc08d1
2: /* anonymous */ [0x2b588723b4a9] [/home/jstanford/.nvm/versions/node/v12.16.3/lib/node_modules/cabal/views.js:158] [bytecode=0x1ed3275b1dc9 offset=161](this=0x181dcc97fd81 ,0x26e357d61ff1 )
3: arguments adaptor frame: 3->1
4: map [0x292556dd5911](this=0x1f4b20f4aa99 <JSArr...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: 0xa09830 node::Abort() [node]
2: 0xa09c55 node::OnFatalError(char const*, char const*) [node]
3: 0xb7d71e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xb7da99 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xd2a1f5 [node]
6: 0xd3ab08 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
7: 0xd07281 v8::internal::Factory::NewTransitionArray(int, int) [node]
8: 0xf4fc07 v8::internal::TransitionsAccessor::Insert(v8::internal::Handlev8::internal::Name, v8::internal::Handlev8::internal::Map, v8::internal::SimpleTransitionFlag) [node]
9: 0xefc957 v8::internal::Map::ConnectTransition(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::Name, v8::internal::SimpleTransitionFlag) [node]
10: 0xefef8e v8::internal::Map::CopyReplaceDescriptors(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::DescriptorArray, v8::internal::Handlev8::internal::LayoutDescriptor, v8::internal::TransitionFlag, v8::internal::MaybeHandlev8::internal::Name, char const*, v8::internal::SimpleTransitionFlag) [node]
11: 0xeff63a v8::internal::Map::CopyAddDescriptor(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Descriptor*, v8::internal::TransitionFlag) [node]
12: 0xeff879 v8::internal::Map::CopyWithField(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::Name, v8::internal::Handlev8::internal::FieldType,
v8::internal::PropertyAttributes, v8::internal::PropertyConstness, v8::internal::Representation, v8::internal::TransitionFlag) [node]
13: 0xf01042 v8::internal::Map::TransitionToDataProperty(v8::internal::Isolate*, v8::internal::Handlev8::internal::Map, v8::internal::Handlev8::internal::Name, v8::internal::Handlev8::internal::Object, v8::internal::PropertyAttributes, v8::internal::PropertyConstness, v8::internal::StoreOrigin) [node]
14: 0xef170f v8::internal::LookupIterator::PrepareTransitionToDataProperty(v8::internal::Handlev8::internal::JSReceiver, v8::internal::Handlev8::internal::Object, v8::internal::PropertyAttributes, v8::internal::StoreOrigin) [node]
15: 0xf24b06 v8::internal::Object::AddDataProperty(v8::internal::LookupIterator*, v8::internal::Handlev8::internal::Object, v8::internal::PropertyAttributes, v8::Maybev8::internal::ShouldThrow, v8::internal::StoreOrigin) [node]
16: 0xf256f7 v8::internal::Object::SetProperty(v8::internal::LookupIterator*, v8::internal::Handlev8::internal::Object, v8::internal::StoreOrigin, v8::Maybev8::internal::ShouldThrow) [node]
17: 0x1059d64 v8::internal::Runtime::SetObjectProperty(v8::internal::Isolate*, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, v8::internal::StoreOrigin, v8::Maybev8::internal::ShouldThrow) [node]
18: 0x105af2a v8::internal::Runtime_SetKeyedProperty(int, unsigned long*, v8::internal::Isolate*) [node]
19: 0x13c5b79 [node]
Aborted (core dumped)

[okdistribute]

This seems to be cli-only, the desktop app does not have a memory leak.

Is there special library that cabal-cli is using to render things that might need investigation/updating?

[hackergrrl]

Is anyone running a cli with --seed that is also crashing? If yes, it would clarify whether it's related to rendering.

[okdistribute]

@noffle I looked on my vps, looks like I'm getting

 (node:29410) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to HypercoreProtocolStream(

But it is not crashing, it seems to be just a warning.

[bashrc2]

A crash report here. I couldn't get all of it because the screen froze. Version is 13.1.6

[607583:0x55c60f50cbf0] 236714006 ms: Mark-sweep 2026.6 (2056.9) -> 2026.6 (2056.9) MB, 2162.1 / 0.2 ms  (average mu = 0.121, current mu = 0.000) last resort GC in old space requested
[607583:0x55c60f50cbf0] 236716227 ms: Mark-sweep 2027.1 (2057.4) -> 2027.1 (2058.4) MB, 2191.2 / 0.2 ms  (average mu = 0.072, current mu = 0.014) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x55c60ce46881 node::Abort() [node]
 2: 0x55c60cd875ae node::FatalError(char const*, char const*) [node]
 3: 0x55c60cfc8052 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0x55c60cfc82b8 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0x55c60d158f26  [node]
 6: 0x55c60d159069  [node]
 7: 0x55c60d168c1e v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
 8: 0x55c60d169b15 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0x55c60d16c13c v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0x55c60d16c1a4 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
11: 0x55c60d13212c v8::internal::Factory::AllocateRawArray(int, v8::internal::AllocationType) [node]
12: 0x55c60d132859 v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType) [node]
13: 0x55c60d2a3dfe  [node]
14: 0x55c60d2abf3a  [node]
15: 0x55c60d2afc07 v8::internal::ArrayConstructInitializeElements(v8::internal::Handle<v8::internal::JSArray>, v8::internal::Arguments*) [node]
16: 0x55c60d42c5a7 v8::internal::Runtime_NewArray(int, unsigned long*, v8::internal::Isolate*) [node]
17: 0x55c60d784fb9  [node]

[rinchen]

Is anyone running a cli with --seed that is also crashing? If yes, it would clarify whether it's related to rendering.

data point: I am not. Both of my instances that are crashing are Linux (Ubuntu and Debian) with just "cabal" as the command.

[cblgh]

i just started a separate process on a vps, seeding the public cabal without the cli rendering. i'll post again in a few days sharing if it crashed

[cblgh]

i just started a separate process on a vps, seeding the public cabal without the cli rendering. i'll post again in a few days sharing if it crashed

it crashed during the night