Node’s Labours Lost (A v0.3 Release)

When I left off last Sunday I had studied the application of a mutexes in order to make the parser thread-safe. Shortly after that I decided that mutexes probably weren’t the way to go due to their nature as an implementation of a mutex in the alloc function would require either a global variable for every mutex, or that the mutex be passed in with the memory to be allocated every single time. Neither of which are probably a good idea. I was thinking of moving forward with working on the unit-test cases before I would start researching how glibc’s malloc was thread-safe, however I quickly discovered that the unit-testing framework actually wasn’t completed and those involved were having a hard time figuring out how they could fix it. Thus, I decided I could try to help out with the unit-testing framework so that perhaps it might be finished faster.

The first step was to get my machine ready to work with the packages that would be used. I decided that I would use the Ubuntu virtual box I created while testing WebKit as I was certain that it would be a little bit easier to get working with the current build system and the packages that would be involved. It turned out I was only half-right as while the build system was fairly straightforward, Ubuntu doesn’t quite support Node.js readily. The biggest problem it had was that there was already a package called Node which did a completely different thing from Node.js, and thus it needed a different package name (nodejs). Unfortunately, packages installed using npm do not recognize this different name and still expect Node.js to be called using node in the node directory. After wrestling with this issue for a bit, I decided it might be easier to install Node.js from source so I looked up for a guide on how I might accomplish this and found one here. For my installation I made a slight modification by downloading node-v0.8.14 instead of node-v0.6.17 after inquiring another student about what version they had been using. The installation worked out all the same and soon I was on to installing npm packages after discovering that the node package included and installed npm. This was almost all straightforward except for one package. I discovered that there was a node-ffi package and an ffi package and they both worked on node. This confused me a little bit, but after reading the node-ffi github markdown I went with installing the ffi package, which turned out to be the correct one. I had heard that alot of people were having issues installing node, however I never thought that this simple distinction was what was causing so much grief. I feel like I might have been able to increase the productivity of the node-ffi unit tests had I not assumed that no one else had had this issue.

When I started working on fixing the unit test for sample.js I found that quite alot looked done, however there was an issue with node hanging when ffi tried to call the webvtt_parse_chunk function as in the picture below.

Initially I was stumped on how I could even begin to figure out what the problem was however after reading the code I decided to try looking for a tool that could debug node. After some perusing I found a tool called node-inspector. This tool basically allows for the debugging of code in node in a manner similar to Visual Studio or XCode with the ability to do things like step-in/step over code as well as view the contents of variables while using a WebKit enabled browser (i.e. Chrome or Safari). This didn’t exactly solve the problem, but it did make it easier to tell what the problem might have been as well as help discover a few minor errors that had been missed. Using node-inspector I was able to narrow down the issue to the exact function that was causing the grief:

Unfortunately, I was unable to progress much further beyond this point. It looked to me like an issue with what was being passed into the binded C function, however I was unable to find out what exactly was being passed into the C function as Node-inspector would not actually go into the C code. I tried searching the internet for an answer that might help us and there were a few interesting articles about issues that might have been related, however attempting the solutions they provided did not solve the issue. And thus well into Thursday morning, the situation still looks roughly the same.

I think the major thing blocking the progress of the node-ffi testing is that I did not know of a way to peek into the operation of the C code being called from node-ffi. After the discussion in class today however, I feel like perhaps learning how to use GDB would solve this issue and help with the current problem of debugging the code blind. I’d also be interested in modifying the VS project to generate a .dll when compiled directly from Visual Studio as I had looked into doing that before I started working on the node-ffi testing.

Advertisements

2 responses to “Node’s Labours Lost (A v0.3 Release)

    • That’s node-inspector, I found it while looking for a debugger for Javascript. I’ve found it quite useful for debugging, it just requires a WebKit browser like Safari or Chrome and it’ll act almost like debugging in debuggers like Visual Studio or Eclipse. I linked it’s Github repo in my post (where it says node-inspector).
      But I’ll link it here as well: https://github.com/dannycoates/node-inspector.
      You can also get it through npm install.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s