You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Rafael Schloming <rh...@alum.mit.edu> on 2015/02/02 13:43:45 UTC
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 <rh...@alum.mit.edu> wrote:
> On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams <
> fraser.adams@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.adams@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)
>>>>>
>>>>>
>>>>>
>>
>
Re: puzzling issue with javascript bindings
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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 <rh...@alum.mit.edu> wrote:
>
>> On Sat, Jan 31, 2015 at 12:27 PM, Fraser Adams <
>> fraser.adams@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.adams@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)
>>>>>>
>>>>>>
>>>>>>