Hopefully you got the build I mailed you, but as an update I've upgraded
my system to the latest emscripten incoming:
emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.29.8
clang version 3.5.0
And did a Debug build on a clean system as before and I'm still not
seeing any issues like the one you described and my recv.js seems pretty
happy however many times I call send.js
I'm pretty stumped!!
What system are you running? Is there anything quirky? Do you have any
exotic compilers or an unusual path?
Frase
On 31/01/15 15:37, Rafael Schloming wrote:
Any chance you could send me a copy of your proton.js so I can try on my
system?
--Rafael
On Sat, Jan 31, 2015 at 10:32 AM, Fraser Adams <
[email protected]> wrote:
Hi again Rafi,
As I'm on a roll today.....
So I've just done:
cd build
make clean
rm CMakeCache.txt
cmake -DCMAKE_BUILD_TYPE=Debug ..
(which gives the message: JavaScript build type is "Debug")
make
and when I did
./recv.js
and in another window
./send.js
I'm not seeing any issue:
./recv.js
pipe() returning an error as we do not support them
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Address: amqp://0.0.0.0
Subject: UK.WEATHER
Content: "Hello World!"
Looking in
node_modules/qpid-proton-messenger/lib/proton-messenger.js
I've definitely got the unminified/Debug version in play (which is also
borne out by the "pipe() returning an error as we do not support them"
message from emscripten's stub pipe call).
So I'm not seeing what you are seeing on my system.
I'm running Linux Mint 17.1 Rebecca
emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.28.2
clang version 3.4
node v0.10.33
I doubt the changes I've just committed would make any difference, so
there's definitely something weird.
I'll update my emscripten/fastcomp versions and see if that introduces
this quirk.
On the plus side, at least it wasn't my imagination and I really haven't
seen this behaviour before :-D
If it *is* an emscripten issue it'd be good to have a minimal reproducer
to attach to an issue report.
Frase
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)
