garbage collection throwing V8 fatal error

[rstoye]

Hello there, I've been playing around with this library for a while now and I keep running into the following error on different occasions:

#
# Fatal error in , line 0
# Check failed: marking_done_.
#
#
#
#FailureMessage Object: 0x7ffddb6d3a50
----- Native stack trace -----

 1: 0xd20211  [node]
 2: 0x2118e21 V8_Fatal(char const*, ...) [node]
 3: 0x108bf89 v8::internal::CppHeap::TraceEpilogue() [node]
 4: 0x10f3503 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) [node]
 5: 0x10f3d7c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 6: 0x10f4a9a v8::internal::Heap::FinalizeIncrementalMarkingIfComplete(v8::internal::GarbageCollectionReason) [node]
 7: 0x10f642a v8::internal::IncrementalMarkingJob::Task::RunInternal() [node]
 8: 0xd201a6  [node]
 9: 0xd22d5f node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node]
10: 0x188aa33  [node]
11: 0x189f41b  [node]
12: 0x188b757 uv_run [node]
13: 0xbbbb83 node::SpinEventLoopInternal(node::Environment*) [node]
14: 0xcf4d25  [node]
15: 0xcf56ed node::NodeMainInstance::Run() [node]
16: 0xc5f367 node::Start(int, char**) [node]
17: 0x7f4cda639c88  [/usr/lib/libc.so.6]
18: 0x7f4cda639d4c __libc_start_main [/usr/lib/libc.so.6]
19: 0xbb8d7e _start [node]

I have seen this issue https://github.com/UrielCh/opencv4nodejs/issues/134, but sadly had to realize that my problem persists even on node 18 and node 16. So there is no easy workaround it seems.

You can check out my example project https://github.com/rstoye/opencv-troubleshoot where the error happens without fail on my system.

Speaking of systems:

OS: Linux 6.1.92-1-MANJARO OpenCV: 4.9.0

RAM: 32 GB DDR-4 something something

My use case for opencv is that I have tons of scanned documents, that all have a distinct black line in the middle. I'm using this line as a guideline to roughly calculate the angle of the scanned document and correct it, so that the output is a straight document. The document is then being manipulated further, but for the sake of simplicity I only put the straightening process in the example project.

Any help or ideas would be greatly appreciated.

Thank you.

[aovens-quantifi]

@rstoye I was able to get around the issue by switching to the sync methods

[rstoye]

@rstoye I was able to get around the issue by switching to the sync methods

Sadly this didn't work for me. The error still pops up rather quickly.

On the other hand I set up a docker container and ran the example project there and got no errors. Maybe it's an issue with Manjaro / Arch.

[rambo-panda]

@rstoye I was able to get around the issue by switching to the sync methods

this work for me.

imwriteAsync(webpImg) methods will report errors

#FailureMessage Object: 0x7ffda173e380
----- Native stack trace -----

 1: 0xd45071  [node]
 2: 0x218d121 V8_Fatal(char const*, ...) [node]
 3: 0x10c8189 v8::internal::CppHeap::TraceEpilogue() [node]
 4: 0x112f703 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) [node]
 5: 0x112ff7c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 6: 0x1130c9a v8::internal::Heap::FinalizeIncrementalMarkingIfComplete(v8::internal::GarbageCollectionReason) [node]
 7: 0x113262a v8::internal::IncrementalMarkingJob::Task::RunInternal() [node]
 8: 0xd45006  [node]
 9: 0xd485af node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node]
10: 0x18c78a3  [node]
11: 0x18dc31b  [node]
12: 0x18c85c7 uv_run [node]
13: 0xbd3be6 node::SpinEventLoopInternal(node::Environment*) [node]
14: 0xd18824  [node]
15: 0xd192bd node::NodeMainInstance::Run() [node]
16: 0xc7d69f node::Start(int, char**) [node]
17: 0x7fd13414ad7a __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
18: 0xbd12ee _start [node]
Trace/breakpoint trap (core dumped)

[zzz08900]

It appears all async methods can trigger the crash under nodeJS 20. Switch to sync methods uauslly avoids the crashing but things go a lot slower that way.