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