ywave620

Then this design does not make sense to me. It definitely leads to a memory leak. We have to keep track of every `vm.Script` object resulted from `vm.runInThisContext()` because we...

So this is a contradictory design, and that is why we have a crash in https://github.com/nodejs/node/issues/43205#issuecomment-1272209939. We need to pass the `vm.Script` instance to the `importModuleDynamically()` as the 2nd argument,...

Simpler reproducible code Check https://github.com/nodejs/node/issues/44211#issuecomment-1271137984 for the fix I came with :) ```js const vm = require('node:vm') const code = ` new Promise(resolve => { setTimeout(() => { gc(); //...

@G-H-Y Is a long run required for reproducing? Do you have any other easier way to reproduce?

> any progress ? i also meet this segfault in v6.29.5, cpp version v6.29.5 is too old, can you try the latest version

I think you should call TryCatchupWithPrimary() in an enough frequency to for proper data synchronization. WAL is selected for deletion in primary regardless of the secondary

> where some write is not fsynced to file, and missing completely from the file @nkg- I think this only results from write with option.sycn=false, so it is expected to...

I can not reproduce. Any hint about how to reliably repro?

@philmes Could you tell which version of libc and libc++ you are using

**There is a leak! But it is spurious.** In RocksDB, bg threads are resources shared among multiple DB. They won't be recycled until the end of the process. However, since...