libxmljs: Async use of NanAdjustExternalMemory causes crash with Node 0.12.1
I’m using node 0.12.1 and am investigating a segmentation fault in node-libxslt which builds on libxmljs. See albanm/node-libxslt#9.
I found that the segmentation fault occurs in a worker thread (i.e. not the V8 event dispatcher thread) when that thread runs some libxml code, and as a consequence calls NanAdjustExternalMemory at some point. In that thread, v8::Isolate::GetCurrent() will return NULL, causing the crash. The way I understand it, calls to V8 API from threads other than the event dispatcher thread are forbidden, including that Nan call.
Unfortunately I still have to find a good documentation on that AdjustAmountOfExternalAllocatedMemory method of the isolate, to see what repercussions we’d have to expect if we simply stopped telling V8 about our memory usage. But I guess 393b44a0010da5a469222291e9cad6be74f33a4c introduced that code for a reason. That commit is titled “first round of fixes for external memory issues” but doesn’t say what kinds of issues these are. @polotek, do you remember any details?
If there is a really strong reason to keep these functions, then we’ll probably have to work out how to make them function in an asynchroneous world. Implement some libuv signalling which reports adjustments from worker threads back to the event dispatch thread to be fed to V8. I very much hope that we don’t really need this, since it might add considerable synchronization overhead.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 1
- Comments: 33 (19 by maintainers)
Commits related to this issue
- WIP: Make NanAdjustExternalMemory thread-safe Fix #296 — committed to nathan7/libxmljs by edef1c 9 years ago
- Make NanAdjustExternalMemory thread-safe Fixes #296 — committed to nathan7/libxmljs by edef1c 9 years ago
- Make NanAdjustExternalMemory thread-safe Fixes #296 — committed to nathan7/libxmljs by edef1c 9 years ago
- Wrap all allocation and deallocation inside the memory-management mutex Further fix the issues uncovered by #296 — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
- Make memory usage tracking thread-safe Fixes #296. This keeps track of allocation sizes by adding a header to every allocation holding the size. The difference between the memory usage we've last rep... — committed to nathan7/libxmljs by edef1c 9 years ago
@rchipka: This here has been dormant for quite a while now. Are you still interested in getting multi-threading into the master eventually, and thus ending the need for a fork? If so, please let me know which of the named changes you’d like to see merged, and whether you want them in a single merge request or a bunch of cherry-picks. The former would be easier for me.
@rchipka I leave this up to you. I have made my comments on the matter here (https://github.com/polotek/libxmljs/pull/361/files/946a7bedc603b46126f182f8ffe6cb20795d58e5#r58493067). If you want to maintain an updated list and decide who is added based on contribution, go for it! I never cared that much about keeping such a list but have no opposition to you doing so. I contributed not to have my name listed but to create a library to solve my use cases and hope others benefit from that but I can understand how others might care more about name recognition.