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