Thanks for the heads up Rafi.
I'll take a look when I've got a moment, that's not actually something I've noticed before.


TBH I'm *pretty sure* that when I was developing this stuff I'd have done what you've done, so I'm a bit baffled but I've mostly been using non Debug builds lately and it's quite possible that some emscripten change has caused this - it's quite a dynamic project.

Hopefully you noticed my other mail on the ws WebSocket library change borking the bindings, sigh!

Be aware that I'm currently in the process of changing the package name to qpid-proton-messenger.

F.

On 31/01/15 12:17, Rafael Schloming wrote:
Hi,

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://0.0.0.0
Subject: UK.WEATHER
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
14
14

/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:4923
       throw ex;
             ^
abort() at Error
     at jsStackTrace
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:5826:13)
     at stackTrace
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:5843:22)
     at abort
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:76848:25)
     at nullFunc_iii
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11274:705)
     at Array.b686 [as 14]
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:73421:47)
     at _pn_class_new
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11761:39)
     at _pn_map
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:12759:11)
     at _pn_hash
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:13185:11)
     at Array._pn_transport_initialize [as 76]
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:53534:13)
     at _pn_class_new
(/home/rhs/proton/node_modules/qpid-proton/lib/proton.js:11775:29)


Reply via email to