Re: puzzling issue with javascript bindings
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 r...@alum.mit.edu wrote: On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams fraser.ad...@blueyonder.co.uk 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 fraser.ad...@blueyonder.co.uk 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
Re: puzzling issue with javascript bindings
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 r...@alum.mit.edu wrote: On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams fraser.ad...@blueyonder.co.uk 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 fraser.ad...@blueyonder.co.uk 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
Re: puzzling issue with javascript bindings
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 : 0 i: 0 ii: 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
Re: puzzling issue with javascript bindings
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 fraser.ad...@blueyonder.co.uk 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 : 0 i: 0 ii: 0 vii: 0 vi: 0 14 14 /home/rhs/proton/node_modules/qpid-proton/lib/proton.js:4923 throw ex; ^ abort() at Error
Re: puzzling issue with javascript bindings
On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams fraser.ad...@blueyonder.co.uk 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 fraser.ad...@blueyonder.co.uk 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
Re: puzzling issue with javascript bindings
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 : 0 i: 0 ii: 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)
Re: puzzling issue with javascript bindings
On Sat, Jan 31, 2015 at 7:29 AM, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: 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. Yeah, I wondered about that too. I did upgrade from whatever version I installed a few months ago to the latest as of a week or two ago, but it didn't seem to make a difference. Hopefully you noticed my other mail on the ws WebSocket library change borking the bindings, sigh! Yeah Be aware that I'm currently in the process of changing the package name to qpid-proton-messenger. Thanks for the heads up. FWIW, I'm not sure it necessarily makes sense ultimately to have separate packages for the two of them. My plan to reconcile them is basically to refactor messenger into a pure event handler that is a composed of a number of smaller event handlers. This will allow you to use multiple messengers inside a single reactor along with other more explicitly managed connections, and also allow you to customize the behavior of messenger to a much greater degree since you can control how it is assembled from its component handlers and insert your own event handlers if you wish. Ultimately I don't expect them to be alternative APIs, but rather for the reactor to have a library of handlers to choose from that include messenger as a simple entry point that lets you get up and running without having to understand anything other than 'message' and 'address'. Of course this is all just a plan at the moment, so a defensive name change probably makes sense in order to allow us to break compatibility if necessary. I just wanted to be clear that my plan is to avoid having two alternative APIs in the end. --Rafael
