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

Most upvoted comments

@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.