I recently uncovered a puzzling issue with the Javascript bindings. If I
fire up the simple recv.js example and then run send.js, it works fine the
first time, but the second time around I get the error below. This
apparently has been happening for a while (possibly a few months), however
I haven't noticed because it only happens with debug builds, and only then
the second time around. With a regular build everything seems to work fine.

I googled around a bit for this particular error and there are a bunch of
threads talking about how casting function pointers doesn't work with
emscripten and you need to avoid that, but I don't believe we actually do
that ever, and I see nothing to indicate that this sort of error would go
away with a non Debug build.

The stack trace (which you only get after rebuilding with ASSERTIONS=2)
seems pretty straightforward. It is inside pn_class_new which delegates to
a function pointer held in the pn_class_t struct that is passed in. I
believe that function pointer lookup is what is failing, but when I put
printfs in the C code to confirm this, the problem goes away.

At this point I'm kind of left scratching my head. The only thing I can
think of short of a compiler bug is that somehow the pn_class_t struct is
becoming corrupted, but I would expect valgrind to show up any sort of
memory issues like that, unless somehow it is only being triggered from the
javascript binding.

Anyways, I figured I should give people a heads up. The workaround is easy
enough, just build with non Debug build and everything seems to work fine.
Beyond that, any insight would be greatly appreciated.


[rhs@localhost proton]$ examples/messenger/javascript/recv.js
pipe() returning an error as we do not support them
Address: amqp://
Content: "Hello World!"
Invalid function pointer '14' called with signature 'iii'. Perhaps this is
an invalid value (e.g. caused by calling a virtual method on a NULL
pointer)? Or calling a function with an incorrect type, which will fail?
(it is worth building your source files with -Werror (warnings are errors),
as warnings can indicate undefined behavior which can cause this)
This pointer might make sense in another type signature: ii:
_pn_void_reify  iiii: 0  iiiii: 0  iiiiii: 0  vii: 0  vi: 0

      throw ex;
abort() at Error
    at jsStackTrace
    at stackTrace
    at abort
    at nullFunc_iii
    at Array.b686 [as 14]
    at _pn_class_new
    at _pn_map
    at _pn_hash
    at Array._pn_transport_initialize [as 76]
    at _pn_class_new

Reply via email to