Repository navigation
cpu-prof doesn't propagate to workers when env is set #52825
Description
Activity
I've been able to reproduce.
const worker_threads = require('worker_threads'); if (worker_threads.isMainThread) { new worker_threads.Worker(__filename, { env: process.env }); } else { console.log('Hello, world!'); }
node --cpu-prof index.jsThe issue occurs when the
envis set to any value. I'll look into it.I've determined the issue is not on the JS side of things but on the C++ side instead. I'm no CPP expert, so I haven't looked into it much, but I'd assume it is has something to do with the
node_worker.ccfile: https://github.com/nodejs/node/blob/71a1fa3043d495dfaa2105d07cd090c51bcd8eed/src/node_worker.cc(I determined this by fiddling around with the
/lib/internal/worker.jsfile, and seeing that no matter the value set, the issue has to do with theWorkerImpl, implemented in CPP)CC @nodejs/workers
- added a commit that references this issue
on May 12, 2024 - added a commit that references this issue
on May 12, 2024 - added a commit that references this issue
on Jun 20, 2024 - added a commit that references this issue
on Sep 21, 2024
Version
20.8.1
Platform
Linux ushanka-housing 6.5.0-1020-oem #21-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 3 14:54:32 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
cpu-prof
What steps will reproduce the bug?
You can reproduce this by modifying one of the existent node tests.
If you edit
tests/fixtures/workload/fibonacci-worker.jsin this repo withand then run
the new test will fail
How often does it reproduce? Is there a required condition?
This should reproduce 100% of the time -- you don't need to do anything special
What is the expected behavior? Why is that the expected behavior?
According to https://nodejs.org/docs/latest-v20.x/api/worker_threads.html#new-workerfilename-options, the default value for a worker thread's env is process.env. Thus, not passing an environment and passing process.env as the environment should always produce the same behavior.
What do you see instead?
When running in its original form, the test produces two profile files, as intended. When passing
{env: process.env}into the worker invocation, however, it only produces one profile file.Additional information
If I print the environment in the worker thread, it appears to be identical in both cases. It doesn't seem like the problem is that part of the environment is getting lost, but rather there's some hidden variable that isn't getting propagated