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 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) >> >> >
