That's very generous of Rafael - he spotted the wood when I was still
staring at the trees :-) I was quite impressed.
I think I can at least claim the dubious honour of being one of the very
few people who has managed to introduce an uninitialised pointer error
into JavaScript code! I don't know whether to be embarrassed or proud :-D
Frase
On 02/02/15 12:43, Rafael Schloming wrote:
FYI, thanks to some help from Fraser, this issue should now be resolved.
--Rafael
On Sat, Jan 31, 2015 at 1:24 PM, Rafael Schloming <[email protected]> wrote:
On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams <
[email protected]> wrote:
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?
I did get your build and it worked fine for me. I emailed you a copy of
my build just in case you are curious. My versions are:
emcc (Emscripten GCC-like replacement) 1.29.0 (commit
fdf24b478e1b26c0362a1627aca49ef82fd53f6a)
clang version 3.4
My system is just stock fedora 20 as far as I'm aware. I installed
emscripten by just following the directions in the README.
--Rafael
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)
