Fix a Windows-only load time linker error caused by nodejs/io.js@efadffe ("win,node-gyp: optionally allow node.exe/iojs.exe to be renamed"), which was made the default in io.js v2.2.0. Fixes the following error whe trying to load the add-on: LINK : fatal error LNK1194: cannot delay-load "iojs.exe" due to import of data symbol ""__declspec(dllimpo rt) const v8::OutputStream::`vftable'" (__imp_??_7OutputStream@v8@@6B@)"; link without /DELAYLOAD:iojs.exe Fixes #57.
Fork-before-snapshotting is fundamentally incompatible with newer V8 releases. V8 uses threads now but those don't survive the call to fork(). Then, when creating the snapshot, V8 tries to sync up with a thread that no longer exists and deadlocks. Another issue is that forking breaks the comparison view in DevTools because the heap object IDs don't match up. V8 updates them after creating the snapshot but those changes don't make it back to the parent process. Fixes #37 and #41.
The tests assumed that `process.cwd() == __dirname` when scanning for files but did not actually enforce that. The result was that `cd test && node test-sigusr2.js` worked but `node test/test-sigusr2.js` did not. This commit fixes that by always chdir'ing into test/ first.
Include node.h so the BUILDING_NODE_EXTENSION macro can work its magic and exports V8 functions and types properly. Fixes the following build error: node.lib(node.exe) : error LNK2005: "public: __cdecl v8::Handle<class v8::Object>::Handle<class v8::Object>(class v8::Object *)" (??0?$Handle@VObject@v8@@@v8@@QEAA@PEAVObject@1@@Z) already defined in platform-win32.obj node.lib(node.exe) : error LNK2005: "public: __cdecl v8::Handle<class v8::FunctionTemplate>::Handle<class v8::FunctionTemplate>(void)" (??0?$Handle@VFunctionTemplate@v8@@@v8@@QEAA@XZ) already defined in platform-win32.obj Fixes #30.
Call v8::HeapSnapshot::Delete() to free the memory. Doing so requires a const_cast<> that is currently safe. Let's hope it stays that way with future V8 releases. The memory leak only affects Windows. On UNIX platforms, the snapshot is created in a forked process that exits after writing it to disk. Fixes #24. Fixes #27.
A bug in libuv makes it call `waitpid(-1)` before node-heapdump gets a chance to call `waitpid(pid)` and, as a result, libuv consumes the exit event of the process that node-heapdump forked off. It looks like the bug is not fixable in libuv v0.10 without undue effort so it probably won't get addressed. (Libuv master is unaffected as a side effect of commit joyent/libuv@5c00a0e.) Not all is lost, however: ECHILD means there is no child process with that pid so we know for sure that it's safe to stop our signal watcher. Fixes #22.
Due to fork()'s copy-on-write behavior on modern Unices and the fact that a major garbage collection cycle is performed right afterwards, creating a snapshot may require about 2x the amount of memory that was in use right before the snapshot.