nodejs webworker-threads crashes after a lot of postMessages - node.js

Question

After a lot of postMessages to a webworker I get an abort and stacktrace as shown below in my original question.
I decreased the interval from 250ms to 6ms and then this problem appears earlier in time, about 45min instead of 6-9 hours.
The code is rather simple
mainapp.js
const Worker = require('webworker-threads').Worker;
var myappwebworker = new Worker('./myappwebworker.js');
myappwebworker.addEventListener('message', function(e) {
console.log(e)
});
setInterval(function() {
myappwebworker.postMessage('hello');
}, 250); // or 5 for abort in about 45min
myappwebworker.js
self.addEventListener('message', function(e) {
self.postMessage('You said: ' + e.data);
}, false);
What is the reason for this? Do I run out of heap because the garbage collector don't have time to run or something similar? In any case what can be done to prevent this?
This was the original question until I updated based on my findings
Title:nodejs webworker-threads debugging, where to start?
If I get this kind of stack traces after 7-8 hours of running my nodejs app, how do I start to debug this to find the culprit in my code?
node[3836]: ../src/node_platform.cc:414:std::shared_ptr<node::PerIsolatePlatformData> node::NodePlatform::ForIsolate(v8::Isolate*): Assertion `data' failed.
1: 0x8dc510 node::Abort() [node]
2: 0x8dc5e5 [node]
3: 0x965687 node::NodePlatform::CallOnForegroundThread(v8::Isolate*, v8::Task*) [node]
4: 0xeda2ab v8::internal::IncrementalMarking::Start(v8::internal::GarbageCollectionReason) [node]
5: 0xed4b6c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
6: 0xed7371 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
7: 0xeac650 [node]
8: 0xeac6e7 v8::internal::Factory::NewJSObject(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::PretenureFlag) [node]
9: 0xae84ae v8::Object::New(v8::Isolate*) [node]
10: 0x7ff7eb5f0913 BSONDeserializer::DeserializeDocumentInternal(bool) [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
11: 0x7ff7eb5f0b97 BSONDeserializer::DeserializeDocument(bool) [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
12: 0x7ff7eb5f0f40 BSONDeserializer::DeserializeValue(BsonType, bool) [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
13: 0x7ff7eb5f0946 BSONDeserializer::DeserializeDocumentInternal(bool) [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
14: 0x7ff7eb5f0b97 BSONDeserializer::DeserializeDocument(bool) [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
15: 0x7ff7eb5f3bcf [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
16: 0x7ff7eb5f4519 [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
17: 0x7ff7f25536ba [/lib/x86_64-linux-gnu/libpthread.so.0]
18: 0x7ff7f228941d clone [/lib/x86_64-linux-gnu/libc.so.6]
Here is a similar stack trace
1: 0x8dc510 node::Abort() [node]
2: 0x8dc5e5 [node]
3: 0x965687 node::NodePlatform::CallOnForegroundThread(v8::Isolate*, v8::Task*) [node]
4: 0xeda2ab v8::internal::IncrementalMarking::Start(v8::internal::GarbageCollectionReason) [node]
5: 0xed4b6c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
6: 0xed7371 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
7: 0xe9f655 [node]
8: 0xea6eca v8::internal::Factory::NewRawOneByteString(int, v8::internal::PretenureFlag) [node]
9: 0xea71db v8::internal::Factory::NewStringFromOneByte(v8::internal::Vector<unsigned char const>, v8::internal::PretenureFlag) [node]
10: 0xea7c2d v8::internal::Factory::NewStringFromUtf8(v8::internal::Vector<char const>, v8::internal::PretenureFlag) [node]
11: 0xae7ba9 v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [node]
12: 0x7fa4984eda83 Nan::imp::Factory<v8::String>::return_t Nan::New<v8::String, char*>(char*) [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
13: 0x7fa4984e82ab BSON::BSON() [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
14: 0x7fa4984e9b9e [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
15: 0x7fa4984ea519 [/home/ubuntu/myapp/node_modules/webworker-threads/build/Release/WebWorkerThreads.node]
16: 0x7fa49c2cd6ba [/lib/x86_64-linux-gnu/libpthread.so.0]
17: 0x7fa49c00341d clone [/lib/x86_64-linux-gnu/libc.so.6]
There are messages posted at least 4 times a second to the webworker and the code
The webworker is set up in this fashion
const Worker = require('webworker-threads').Worker;
mywebworker = new Worker('./myappwebworker.js');
setInterval(function() {
mywebworker.postMessage('hello');
}, 250);
Other events also trigger messages to the worker. The system is Ubuntu 16.04 and node V10.15.3
In node what is the best method to find the problem causing this?

Answer 1

Two things come to mind.
If you leave the debug window open, depending on the application, trash collection can be halted, causing this kind of issue. Caught me out several times with hard working processes such as video through OpenCV.
setInterval() I believe, won't care if the inner-code is executed or is blocking (That is, blocking when it shouldn't be or blocking too long).
If blocked for more than 250ms, you'll be building up the stack.
Perhaps this kind of code will give you a better debugging experience, if postMessage halts, you'll not build up stack:
function doIt() {
mywebworker.postMessage('hello');
setTimeout(function() {
doIt();
},250);
}
doIt();