Exception thrown from addon

[gabrielschulhof]

In 0.10, when throwing an exception from a C++ addon it would be printed and the process would exit. In 0.12, the exception is not printed, and the process just exits. This makes it really difficult to inform the user about missing stuff or invalid data.

[trevnorris]

Will need more information, test case, etc. before we can help.

[gabrielschulhof]

I'm having some difficulties producing a simple test case, because the addon where the error is happening links to a third-party library, and the exception is thrown from native code in response to an asynchronous network event received by the native library (since the main project concerns itself with providing bindings for the library).

Here's one way to reproduce the problem (tested on Fedora 21) using the actual project:

1. Set up nvm with versions 0.12 and 0.10
2. install unzip, make, scons, a C and C++ compiler, and headers for boost, libuuid, and libcurl
3. wget -O iotivity-node.tar.gz https://github.com/otcshare/iotivity-node/tarball/736665c3f7c2a4440449d70020e62841e6510d8e/
4. tar xvzf iotivity-node.tar.gz
5. cd otcshare-iotivity-node-736665c
6. npm install - this should download, build, and install iotivity, and build the iotivity-node bindings
7. Turn off your firewall and open a second terminal into the directory otcshare-iotivity-node-736665c
8. In both terminals nvm use 0.12
9. In the first terminal, type node js/server.discoverable.js
10. In the second terminal, type node js/client.discovery.js

At this point, the client will quit silently after a short while. Now,

1. Interrupt the server
2. nvm use 0.10
3. npm install
4. In the other terminal (where the client was running), nvm use 0.10
5. In one terminal, node js/server.discoverable.js
6. In the other terminal, ``node js/client.discovery.js`

At this point, after a short while you will see an exception complaining about an unsupported payload type. This is the desired behaviour, not the silence you get with node 0.12.

I'm sorry I can't come up with anything shorter :/

[bnoordhuis]

When you say "exception", do you mean C++ code throwing a C++ exception or raising a JS exception with v8:::Isolate::ThrowException()?

[gabrielschulhof]

The latter. The bindings code generates a JS exception that is never printed. I use nan though: https://github.com/otcshare/iotivity-node/blob/736665c3f7c2a4440449d70020e62841e6510d8e/src/structures/oc-payload.cc#L232

[gabrielschulhof]

I'm still trying to stub out the library, BTW. It uses a processing loop, so, like,

setInterval( function() {
  iotivity.OCProcess();
}, 1000 );

So OCProcess(), ends up calling a function, which ends up calling a function, etc., which ultimately ends up calling js_OCPayload(), which then throws the exception.

So, I'm trying to replace the library with a simple routine that just throws an exception after so many calls to the native function.

EDIT I mean setInterval() - I updated the code above.

[gabrielschulhof]

Well, it's not as simple as that, it seems. This produces the exception in the terminal with both 0.12 and 0.10.

[bnoordhuis]

If you use node::MakeCallback() or nan::MakeCallback(), note that it swallows exceptions. It passes them to the domains handler if there is one but otherwise it just swallows them. There is a bug report about it but I can't find it.

[gabrielschulhof]

@bnoordhuis I commented out the MakeCallback() and the exception is now thrown. Thus, it seems this is indeed related to that issue.

Was nodejs/nan#284 the issue you were looking for?

[gabrielschulhof]

In particular, nodejs/nan#284 (comment)

[bnoordhuis]

That's probably it. I thought there was an io.js issue about it as well but maybe I've mixed up things.

[trevnorris]

MakeCallback() currently should only be used if it's the first JS frame on the call stack. Further calls are undefined behavior. Of course this is not optimal, but the few times I've attempted to fix this in the past there have been edge cases that pop up and still make it unsafe.

[gabrielschulhof]

@trevnorris how do you mean the "first JS frame on the call stack"?

The call stack in my case starts with a JS interval callback firing, which calls a binding that goes deep into the library for which I'm providing bindings. The library, in turn, calls a C function pointer I gave it earlier which gives me a pointer to the Persistent<Function> storing the JS callback I end up calling.

So, the stack is like

setInterval() callback in Javascript -> addon.OCProcess(); -> bind_OCProcess() /* C++ binding */ -> OCProcess() /* C API */ -> /* deep into C library */ -> ( *callback )( void *pointerThatIsReallyAPersistentFunction ) -> NanMakeCallback( ... ) -> /* Back into Javascript */

Does this qualify as "the first JS frame on the call stack"?

[trevnorris]

@gabrielschulhof In your case the setInterval() callback is the first frame in the call stack. If ever you reach C++ from JS then the call back into JS shouldn't use MakeCallback().

[gabrielschulhof]

@trevnorris Thanks!