You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
09:20:31 not ok 3156 pummel/test-worker-take-heapsnapshot
09:20:32 ---
09:20:32 duration_ms: 0.665
09:20:32 severity: crashed
09:20:32 exitcode: -6
09:20:32 stack: |-
09:20:32 (node:38339010) internal/test/binding: These APIs are for internal testing only. Do not use them.
09:20:32 (Use `node --trace-warnings ...` to show where the warning was created)
09:20:32 FATAL ERROR: HandleScope::HandleScope Entering the V8 API without proper locking in place
09:20:32 ...
@richardlau - possible. That issue hints at a race condition (between whom? main thread and the worker thread may be?), given that the issue is easily reproducible with debug build. What I suspect is that once created, the worker thread is able to progress too fast for the main thread, w. r. t. preparing the snapshot collection. But what sequence would need to be executed to fully bootstrap the process? I don't know about that. But this can explain why issue is pronounced in AIX, where the child thread stands better chance to get the CPU than the parent thread. If I were to attempt a recreate (I don't have an AIX box right now), I will select a box with either limited CPUs (< 10) or with a lot of unrelated CPU bound processes running (so as to force CPU contention between main and worker thread, and hope the worker will win the race) and run this test a thousand times.
Activity
richardlau commentedon Aug 12, 2021
Could this be related to #37069?
gireeshpunathil commentedon Aug 12, 2021
@richardlau - possible. That issue hints at a race condition (between whom? main thread and the worker thread may be?), given that the issue is easily reproducible with debug build. What I suspect is that once created, the worker thread is able to progress
too fastfor the main thread, w. r. t. preparing the snapshot collection. But what sequence would need to be executed to fully bootstrap the process? I don't know about that. But this can explain why issue is pronounced in AIX, where the child thread stands better chance to get the CPU than the parent thread. If I were to attempt a recreate (I don't have an AIX box right now), I will select a box with either limited CPUs (< 10) or with a lot of unrelated CPU bound processes running (so as to force CPU contention between main and worker thread, and hope the worker will win the race) and run this test a thousand times.lpinca commentedon Jun 29, 2023
I think this was fixed by #44515, closing.