liblo-devel Mailing List for LibLO

Great!  I will not be able to test this until I am back from vacation. 

--
Cam

On 25 juil. 2013, at 15:35, Stephen Sinclair <rad...@gm...> wrote:

> Okay, so I think I figured out what happened.
> 
> The idea behind changing the LO_MARKER_A/B constants to 64-bit values
> was because on 64-bit machines, the upper 32 bits of these values was
> undefined.  Therefore, on 64-bit machines, the comparison could fail
> unless all 64 bits were defined.
> 
> The fix was to specify these bits, however this broke backward ABI
> compatibility since builds against 0.26 would still not have these
> bits defined, but liblo 0.27 was now expecting all 64 bits to be
> defined.  Previously it might have worked in circumstances where the
> upper 32 bits were set to zero.
> 
> Anyways, I think the solution is to explicitly only compare the bottom
> 32 bits.  A patch in a branch called "x86_64" on my github contains a
> fix, which seems to work for old binaries of SooperLooper and Ardour.
> 
> https://github.com/radarsat1/liblo/tree/x86_64
> 
> Please test!  I haven't yet tested on other architectures.
> 
> Steve
> 
> 
> On Thu, Jul 25, 2013 at 12:04 PM, Stephen Sinclair <rad...@gm...> wrote:
>> Exactly, the markers are implicitly part of the binary interface,
>> which is something I didn't consider properly when applying that
>> patch.
>> 
>> Still, the fact that it doesn't resolve compatibility for SooperLooper
>> confuses me.  Looking into it..
>> 
>> Steve
>> 
>> 
>> On Wed, Jul 24, 2013 at 7:50 PM, Camille Troillard
>> <ca...@os...> wrote:
>>> Hi Steve,
>>> 
>>> I have read the commit you are referring to and here are my thoughts:
>>> 
>>> Changing the value of the LO_MARKER_A/B will not cause an ABI breakage, however as the values "leak out" from lo_send, then the markers can not be found as the old values are used instead. I believe this confirms what you are observing.
>>> 
>>> The commit is 4 years old so I am surprised it did not cause problems in previous releases.
>>> 
>>> Now, when I read the code, I wonder if the change to the marker values was really needed, but I remember using those values fixed a bug. I have to dig into the list emails to see if I said something about it when I sent the patch.
>>> 
>>> --
>>> Cam
>>> 
>>> 
>>> On 24 juil. 2013, at 17:22, Stephen Sinclair <rad...@gm...> wrote:
>>> 
>>>> Hi list,
>>>> 
>>>> So I finally located an actual ABI incompatibility due to 64-bit-ness
>>>> that was introduced post 0.26.
>>>> 
>>>> In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
>>>> for unmatched arguments at the end of the lo_send() call was changed
>>>> to fix problems with 64-bit.  The LO_MARKER_A/B constants were
>>>> extended to 64-bit values.
>>>> 
>>>> Unfortunately, code that was not re-compiled against 0.27 that called
>>>> lo_send() broke after this change, since the LO_MARKER_A/B constants
>>>> are hard-coded into the calling code.  I have verified that swapping
>>>> out the liblo binary for 0.27 when running Ardour generates a message
>>>> "mismatching types and data".  Changing the LO_MARKERs back to their
>>>> previous values avoids this error message.
>>>> 
>>>> Camille, do you recall whether this commit actually fixed a bug (as
>>>> noted in the commit comment), or was it just precautionary?  If the
>>>> latter, do you think it's safe to change it back?
>>>> 
>>>> Steve
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> See everything from the browser to the database with AppDynamics
>>>> Get end-to-end visibility with application monitoring from AppDynamics
>>>> Isolate bottlenecks and diagnose root cause in seconds.
>>>> Start your free trial of AppDynamics Pro today!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Okay, so I think I figured out what happened.

The idea behind changing the LO_MARKER_A/B constants to 64-bit values
was because on 64-bit machines, the upper 32 bits of these values was
undefined.  Therefore, on 64-bit machines, the comparison could fail
unless all 64 bits were defined.

The fix was to specify these bits, however this broke backward ABI
compatibility since builds against 0.26 would still not have these
bits defined, but liblo 0.27 was now expecting all 64 bits to be
defined.  Previously it might have worked in circumstances where the
upper 32 bits were set to zero.

Anyways, I think the solution is to explicitly only compare the bottom
32 bits.  A patch in a branch called "x86_64" on my github contains a
fix, which seems to work for old binaries of SooperLooper and Ardour.

https://github.com/radarsat1/liblo/tree/x86_64

Please test!  I haven't yet tested on other architectures.

Steve


On Thu, Jul 25, 2013 at 12:04 PM, Stephen Sinclair <rad...@gm...> wrote:
> Exactly, the markers are implicitly part of the binary interface,
> which is something I didn't consider properly when applying that
> patch.
>
> Still, the fact that it doesn't resolve compatibility for SooperLooper
> confuses me.  Looking into it..
>
> Steve
>
>
> On Wed, Jul 24, 2013 at 7:50 PM, Camille Troillard
> <ca...@os...> wrote:
>> Hi Steve,
>>
>> I have read the commit you are referring to and here are my thoughts:
>>
>> Changing the value of the LO_MARKER_A/B will not cause an ABI breakage, however as the values "leak out" from lo_send, then the markers can not be found as the old values are used instead. I believe this confirms what you are observing.
>>
>> The commit is 4 years old so I am surprised it did not cause problems in previous releases.
>>
>> Now, when I read the code, I wonder if the change to the marker values was really needed, but I remember using those values fixed a bug. I have to dig into the list emails to see if I said something about it when I sent the patch.
>>
>> --
>> Cam
>>
>>
>> On 24 juil. 2013, at 17:22, Stephen Sinclair <rad...@gm...> wrote:
>>
>>> Hi list,
>>>
>>> So I finally located an actual ABI incompatibility due to 64-bit-ness
>>> that was introduced post 0.26.
>>>
>>> In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
>>> for unmatched arguments at the end of the lo_send() call was changed
>>> to fix problems with 64-bit.  The LO_MARKER_A/B constants were
>>> extended to 64-bit values.
>>>
>>> Unfortunately, code that was not re-compiled against 0.27 that called
>>> lo_send() broke after this change, since the LO_MARKER_A/B constants
>>> are hard-coded into the calling code.  I have verified that swapping
>>> out the liblo binary for 0.27 when running Ardour generates a message
>>> "mismatching types and data".  Changing the LO_MARKERs back to their
>>> previous values avoids this error message.
>>>
>>> Camille, do you recall whether this commit actually fixed a bug (as
>>> noted in the commit comment), or was it just precautionary?  If the
>>> latter, do you think it's safe to change it back?
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Exactly, the markers are implicitly part of the binary interface,
which is something I didn't consider properly when applying that
patch.

Still, the fact that it doesn't resolve compatibility for SooperLooper
confuses me.  Looking into it..

Steve


On Wed, Jul 24, 2013 at 7:50 PM, Camille Troillard
<ca...@os...> wrote:
> Hi Steve,
>
> I have read the commit you are referring to and here are my thoughts:
>
> Changing the value of the LO_MARKER_A/B will not cause an ABI breakage, however as the values "leak out" from lo_send, then the markers can not be found as the old values are used instead. I believe this confirms what you are observing.
>
> The commit is 4 years old so I am surprised it did not cause problems in previous releases.
>
> Now, when I read the code, I wonder if the change to the marker values was really needed, but I remember using those values fixed a bug. I have to dig into the list emails to see if I said something about it when I sent the patch.
>
> --
> Cam
>
>
> On 24 juil. 2013, at 17:22, Stephen Sinclair <rad...@gm...> wrote:
>
>> Hi list,
>>
>> So I finally located an actual ABI incompatibility due to 64-bit-ness
>> that was introduced post 0.26.
>>
>> In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
>> for unmatched arguments at the end of the lo_send() call was changed
>> to fix problems with 64-bit.  The LO_MARKER_A/B constants were
>> extended to 64-bit values.
>>
>> Unfortunately, code that was not re-compiled against 0.27 that called
>> lo_send() broke after this change, since the LO_MARKER_A/B constants
>> are hard-coded into the calling code.  I have verified that swapping
>> out the liblo binary for 0.27 when running Ardour generates a message
>> "mismatching types and data".  Changing the LO_MARKERs back to their
>> previous values avoids this error message.
>>
>> Camille, do you recall whether this commit actually fixed a bug (as
>> noted in the commit comment), or was it just precautionary?  If the
>> latter, do you think it's safe to change it back?
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Steve,

I have read the commit you are referring to and here are my thoughts:

Changing the value of the LO_MARKER_A/B will not cause an ABI breakage, however as the values "leak out" from lo_send, then the markers can not be found as the old values are used instead. I believe this confirms what you are observing.

The commit is 4 years old so I am surprised it did not cause problems in previous releases.

Now, when I read the code, I wonder if the change to the marker values was really needed, but I remember using those values fixed a bug. I have to dig into the list emails to see if I said something about it when I sent the patch. 

--
Cam


On 24 juil. 2013, at 17:22, Stephen Sinclair <rad...@gm...> wrote:

> Hi list,
> 
> So I finally located an actual ABI incompatibility due to 64-bit-ness
> that was introduced post 0.26.
> 
> In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
> for unmatched arguments at the end of the lo_send() call was changed
> to fix problems with 64-bit.  The LO_MARKER_A/B constants were
> extended to 64-bit values.
> 
> Unfortunately, code that was not re-compiled against 0.27 that called
> lo_send() broke after this change, since the LO_MARKER_A/B constants
> are hard-coded into the calling code.  I have verified that swapping
> out the liblo binary for 0.27 when running Ardour generates a message
> "mismatching types and data".  Changing the LO_MARKERs back to their
> previous values avoids this error message.
> 
> Camille, do you recall whether this commit actually fixed a bug (as
> noted in the commit comment), or was it just precautionary?  If the
> latter, do you think it's safe to change it back?
> 
> Steve
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Okay, now I'm confused.

I made a mistake in the previous mail.  In fact SooperLooper does NOT
emit the error message when run against 0.26.  Additionally,

* It does NOT emit it when run against the version prior to 9adc42b1112.
* It DOES emit it when run against 9adc42b1112.
* It DOES emit it on current master.
* And it still DOES emit it on current master if I change the
LO_MARKER_A/B values back to how they were prior to 9adc42b1112.

This is different from the Ardour results, and I should note that this
completely breaks the SooperLooper GUI.  Something is going on here,
I'll continue to investigate.

Steve


On Wed, Jul 24, 2013 at 5:34 PM, Stephen Sinclair <rad...@gm...> wrote:
> I'll note that otherwise, it seems that Ardour can receive OSC
> messages, and apparently responds to incoming instructions without
> problem.  I can't see how to get it to send OSC messages however.
> (Though obviously something is sent on start-up, since I see that
> error message.)
>
> I tested SooperLooper as well, and seem to get "mismatching types and
> data" in both conditions.  However, I *also* get this messages when
> running against the Ubuntu version of liblo (0.26), so maybe there is
> some other issue.
>
> I will try a few more results from "apt-cache rdepends liblo7" to see
> if more problems show up.
>
> Steve
>
>
> On Wed, Jul 24, 2013 at 5:22 PM, Stephen Sinclair <rad...@gm...> wrote:
>> Hi list,
>>
>> So I finally located an actual ABI incompatibility due to 64-bit-ness
>> that was introduced post 0.26.
>>
>> In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
>> for unmatched arguments at the end of the lo_send() call was changed
>> to fix problems with 64-bit.  The LO_MARKER_A/B constants were
>> extended to 64-bit values.
>>
>> Unfortunately, code that was not re-compiled against 0.27 that called
>> lo_send() broke after this change, since the LO_MARKER_A/B constants
>> are hard-coded into the calling code.  I have verified that swapping
>> out the liblo binary for 0.27 when running Ardour generates a message
>> "mismatching types and data".  Changing the LO_MARKERs back to their
>> previous values avoids this error message.
>>
>> Camille, do you recall whether this commit actually fixed a bug (as
>> noted in the commit comment), or was it just precautionary?  If the
>> latter, do you think it's safe to change it back?
>>
>> Steve

I'll note that otherwise, it seems that Ardour can receive OSC
messages, and apparently responds to incoming instructions without
problem.  I can't see how to get it to send OSC messages however.
(Though obviously something is sent on start-up, since I see that
error message.)

I tested SooperLooper as well, and seem to get "mismatching types and
data" in both conditions.  However, I *also* get this messages when
running against the Ubuntu version of liblo (0.26), so maybe there is
some other issue.

I will try a few more results from "apt-cache rdepends liblo7" to see
if more problems show up.

Steve


On Wed, Jul 24, 2013 at 5:22 PM, Stephen Sinclair <rad...@gm...> wrote:
> Hi list,
>
> So I finally located an actual ABI incompatibility due to 64-bit-ness
> that was introduced post 0.26.
>
> In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
> for unmatched arguments at the end of the lo_send() call was changed
> to fix problems with 64-bit.  The LO_MARKER_A/B constants were
> extended to 64-bit values.
>
> Unfortunately, code that was not re-compiled against 0.27 that called
> lo_send() broke after this change, since the LO_MARKER_A/B constants
> are hard-coded into the calling code.  I have verified that swapping
> out the liblo binary for 0.27 when running Ardour generates a message
> "mismatching types and data".  Changing the LO_MARKERs back to their
> previous values avoids this error message.
>
> Camille, do you recall whether this commit actually fixed a bug (as
> noted in the commit comment), or was it just precautionary?  If the
> latter, do you think it's safe to change it back?
>
> Steve

Hi list,

So I finally located an actual ABI incompatibility due to 64-bit-ness
that was introduced post 0.26.

In commit 9adc42b111, a bug in using the LO_MARKER_A/B scheme to check
for unmatched arguments at the end of the lo_send() call was changed
to fix problems with 64-bit.  The LO_MARKER_A/B constants were
extended to 64-bit values.

Unfortunately, code that was not re-compiled against 0.27 that called
lo_send() broke after this change, since the LO_MARKER_A/B constants
are hard-coded into the calling code.  I have verified that swapping
out the liblo binary for 0.27 when running Ardour generates a message
"mismatching types and data".  Changing the LO_MARKERs back to their
previous values avoids this error message.

Camille, do you recall whether this commit actually fixed a bug (as
noted in the commit comment), or was it just precautionary?  If the
latter, do you think it's safe to change it back?

Steve

Steve,
thanx for your answer and your precision about getnameinfo().
I can live with ipv4...

best regards,
nicolas



2013/7/22 Stephen Sinclair <rad...@gm...>

> On Mon, Jul 22, 2013 at 12:17 PM, nicolas bats <sl1...@gm...>
> wrote:
> > Hi Stephen, everyone,
> > I've compiled liblo-0.27 with --enable-ipv6 option.
> > my router is NOT ipv6 capable
> > when I invoke lo_server_new() wich leads to
> > lo_server_new_with_proto_internal() with LO_UDP protocol, it takes
> several
> > seconds to pass this piece of code (around line 540 in server.c) :
> >
> >     /* Try it the IPV6 friendly way first */
> >
> >     for (it = ai; it; it = it->ai_next) {
> >
> >         if (getnameinfo(it->ai_addr, it->ai_addrlen, hostname,
> >
> >                         sizeof(hostname), NULL, 0, NI_NAMEREQD) == 0) {
> >
> >             break;
> >
> >         }
> >
> >     }
> >
> >
> > liblo compiled without --enable-ipv6 works fine with my router.
> >
> > is it something you can fix?, do you need more informations?
>
> Hi, yes the call to getnameinfo() has always been quite slow, which is
> why we stopped defaulting to it when not using IPv6.  I would say, in
> general, that the IPv6 protocol support is still not at 100%.
> Currently it doesn't pass "make test" for me, failing when replying to
> a multicast message.
>
> I would only use --enable-ipv6 if you think you could contribute to
> fixing any problems that crop up.  (Which would be great!)
>
> Steve
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Mon, Jul 22, 2013 at 12:17 PM, nicolas bats <sl1...@gm...> wrote:
> Hi Stephen, everyone,
> I've compiled liblo-0.27 with --enable-ipv6 option.
> my router is NOT ipv6 capable
> when I invoke lo_server_new() wich leads to
> lo_server_new_with_proto_internal() with LO_UDP protocol, it takes several
> seconds to pass this piece of code (around line 540 in server.c) :
>
>     /* Try it the IPV6 friendly way first */
>
>     for (it = ai; it; it = it->ai_next) {
>
>         if (getnameinfo(it->ai_addr, it->ai_addrlen, hostname,
>
>                         sizeof(hostname), NULL, 0, NI_NAMEREQD) == 0) {
>
>             break;
>
>         }
>
>     }
>
>
> liblo compiled without --enable-ipv6 works fine with my router.
>
> is it something you can fix?, do you need more informations?

Hi, yes the call to getnameinfo() has always been quite slow, which is
why we stopped defaulting to it when not using IPv6.  I would say, in
general, that the IPv6 protocol support is still not at 100%.
Currently it doesn't pass "make test" for me, failing when replying to
a multicast message.

I would only use --enable-ipv6 if you think you could contribute to
fixing any problems that crop up.  (Which would be great!)

Steve

Hi Stephen, everyone,
I've compiled liblo-0.27 with --enable-ipv6 option.
my router is NOT ipv6 capable
when I invoke lo_server_new() wich leads to
lo_server_new_with_proto_internal() with LO_UDP protocol, it takes several
seconds to pass this piece of code (around line 540 in server.c) :

    /* Try it the IPV6 friendly way first */

    for (it = ai; it; it = it->ai_next) {

        if (getnameinfo(it->ai_addr, it->ai_addrlen, hostname,

                        sizeof(hostname), NULL, 0, NI_NAMEREQD) == 0) {

            break;

        }

    }


liblo compiled without --enable-ipv6 works fine with my router.

is it something you can fix?, do you need more informations?

best regards,

Nicolas

On Fri, Jul 19, 2013 at 6:39 PM, J. Liles <mal...@gm...> wrote:
>
> On Fri, Jul 19, 2013 at 9:28 AM, Felipe Sateler <fsa...@gm...> wrote:
>>
>> On Fri, Jul 19, 2013 at 10:43 AM, Stephen Sinclair <rad...@gm...>
>> wrote:
>> > - check that ABI is backward-compatible replacing the .so
>> >   (should i add back the lo_server_recv_raw_stream symbol ?)
>>
>> I'd say no. Users of private interfaces get what they deserve when
>> that interface goes away.
>
>
> Agreed, but maybe he meant add it back just for testing whether it broke
> anything to remove it or not.

Yeah, I think if there were actual referenced symbols being dropped
like lo_server_recv_raw_stream(), the problem would have shown up
immediately as a crash.  If there are any problems replacing the
binary, it's something more subtle I'm afraid.

>> There is some testing to be done between apps using 0.26 and 0.27. The
>> issues J. Liles reported look more of a protocol break rather than abi
>> break.
>>
>> Perhaps the testsuite can be enhanced to run different endpoints with
>> different versions of the library?
>
>
> An excellent idea. I'm pretty sure I had no trace of 0.26 left at the time,
> but you never know... Protocol incompatibility would be more disasterous
> than an ABI change.

Okay, on my 64-bit machine, I just downloaded 0.26, compiled it, and
forced "testlo" from master to run against "subtest" from 0.26.  The
test passed successfully.

I dunno, I'm running out of ideas, but I'll have to try installing
other versions of Linux (e.g. Fedora) and test on those.

I should say that the major changes in terms of protocol have been in
the TCP implementation, which I don't expect to have been widely used
previously.  I also don't _expect_ any incompatibilities there, but
you never know.

Steve

On 07/19/2013 04:43 PM, Stephen Sinclair wrote:
> - remove SO_REUSEPORT

probably make that optional.

gfamfd
IOhannes

On Fri, Jul 19, 2013 at 9:28 AM, Felipe Sateler <fsa...@gm...> wrote:

> On Fri, Jul 19, 2013 at 10:43 AM, Stephen Sinclair <rad...@gm...>
> wrote:
> > - check that ABI is backward-compatible replacing the .so
> >   (should i add back the lo_server_recv_raw_stream symbol ?)
>
> I'd say no. Users of private interfaces get what they deserve when
> that interface goes away.
>

Agreed, but maybe he meant add it back just for testing whether it broke
anything to remove it or not.


> There is some testing to be done between apps using 0.26 and 0.27. The
> issues J. Liles reported look more of a protocol break rather than abi
> break.
>
> Perhaps the testsuite can be enhanced to run different endpoints with
> different versions of the library?
>

An excellent idea. I'm pretty sure I had no trace of 0.26 left at the time,
but you never know... Protocol incompatibility would be more disasterous
than an ABI change.

On Fri, Jul 19, 2013 at 10:43 AM, Stephen Sinclair <rad...@gm...> wrote:
> - check that ABI is backward-compatible replacing the .so
>   (should i add back the lo_server_recv_raw_stream symbol ?)

I'd say no. Users of private interfaces get what they deserve when
that interface goes away.

There is some testing to be done between apps using 0.26 and 0.27. The
issues J. Liles reported look more of a protocol break rather than abi
break.

Perhaps the testsuite can be enhanced to run different endpoints with
different versions of the library?

--

Saludos,
Felipe Sateler

On Fri, Jul 19, 2013 at 10:43 AM, Stephen Sinclair <rad...@gm...>wrote:

> So the good news is that my job recently provided me with a shiny new
> macbook pro, which I've got Linux and OS X (and eventually Windows)
> running on.
>
> Finally, I can test liblo under a variety of conditions, including for
> x86_64.
>
> The bad news is that when I run "make test" for the current master
> using Ubuntu 13.04, I get the following:
>
> TEST SUCCESSFUL
>
> In other words, I don't seem to be able to reproduce many of the
> issues people have been having with the 0.27 release.  (Other than the
> fact that "make test" was hanging, which is now fixed in master.)
>

For those of you still having issues with make test, on my machine (Fedora
19 x86_64)
the test is still hanging due to firewalld. Without firewalld running, you
will
get TEST SUCCESSFUL.

Best,
Tristan


>
> Any ideas on how I could approach this?  If anyone still experiencing
> issues with the current master on any operating system could please
> report it would be appreciated.
>
> To do:
>
> - remove SO_REUSEPORT
> - check that ABI is backward-compatible replacing the .so
>   (should i add back the lo_server_recv_raw_stream symbol ?)
> - remove some configure-generated files from the tarball
>
> Steve
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>



-- 
Tristan Matthews
web: http://tristanswork.blogspot.com

So the good news is that my job recently provided me with a shiny new
macbook pro, which I've got Linux and OS X (and eventually Windows)
running on.

Finally, I can test liblo under a variety of conditions, including for x86_64.

The bad news is that when I run "make test" for the current master
using Ubuntu 13.04, I get the following:

TEST SUCCESSFUL

In other words, I don't seem to be able to reproduce many of the
issues people have been having with the 0.27 release.  (Other than the
fact that "make test" was hanging, which is now fixed in master.)

Any ideas on how I could approach this?  If anyone still experiencing
issues with the current master on any operating system could please
report it would be appreciated.

To do:

- remove SO_REUSEPORT
- check that ABI is backward-compatible replacing the .so
  (should i add back the lo_server_recv_raw_stream symbol ?)
- remove some configure-generated files from the tarball

Steve

On Tue, Jul 9, 2013 at 9:24 PM,  <zmo...@ie...> wrote:
>
> Quoting Stephen Sinclair <rad...@gm...>:
>>>
>>> test run not completed
>>> liblo test FAILED
>>> liblo server error 92 in setsockopt(SO_REUSEPORT): Protocol not available
>>>
>>
>> Weird, that's the first time I've seen this one.
>
> afair, SO_REUSEPORT has been introduced in linux-3.9 (prior it was
> only there on some BSD flavors), and that's why it is *now* starting
> to make problems.
>
> note that SO_RESUSEPORT is usually *not* what we want: it will allow
> multiple applications to open the same port - sounds cool, but the
> packets will be distributed using a round-robin algorithm).
>
> what we usually do want is SO_REUSEADDR.
>

Ah, thanks, that's good to know.  I think setting this flag was copied
from an example somewhere, rather than being properly thought out.
I'll remove it.

Steve

Quoting Stephen Sinclair <rad...@gm...>:
>>
>> test run not completed
>> liblo test FAILED
>> liblo server error 92 in setsockopt(SO_REUSEPORT): Protocol not available
>>
>
> Weird, that's the first time I've seen this one.

afair, SO_REUSEPORT has been introduced in linux-3.9 (prior it was  
only there on some BSD flavors), and that's why it is *now* starting  
to make problems.

note that SO_RESUSEPORT is usually *not* what we want: it will allow  
multiple applications to open the same port - sounds cool, but the  
packets will be distributed using a round-robin algorithm).

what we usually do want is SO_REUSEADDR.

dfmads
IOhannes

On Tue, Jul 9, 2013 at 6:47 PM, J. Liles <mal...@gm...> wrote:
>
>
>
> On Tue, Jul 9, 2013 at 8:54 AM, Stephen Sinclair <rad...@gm...>
> wrote:
>>
>> On Tue, Jul 9, 2013 at 4:56 PM, Felipe Sateler <fsa...@gm...> wrote:
>>
>> > This would mark all functions not explicitly listed in the global
>> > scope as local to the shared library, and thus unavailable for client
>> > applications.
>>
>> Right.  I mean, we do something similar with the .def file in windows,
>> as you point out.  I just haven't seen anything other projects using
>> such an approach on Linux, I figured it wasn't necessary.  Perhaps it
>> would be a cautious step though.
>>
>> > If versioning is desired, a more complex symbol map is required. More
>> > info on this is in the DSO howto by Ulrich Drepper
>> >
>> > http://www.akkadia.org/drepper/dsohowto.pdf
>>
>> Thanks.
>>
>> > I could enable the test suite in debian, I didn't realize there was
>> > one. This should give at least some free testing. However, the
>> > testsuite seems to run forever, is it that long or is there a bug?
>>
>> That's a bug, it should be fixed in the master branch now.
>>
>> Steve
>>
>
> Not to change the subject, but FYI, this is what I get running testlo in git
> master on my 64-bit machine:
>
> [snip]
>
> liblo server error 9912 in /: Invalid message received (expected)
> Reply received from osc.udp://127.0.0.1:16673/
> Reply received from osc.udp://127.0.0.1:16673/
>
>
> test run not completed
> liblo test FAILED
> liblo server error 92 in setsockopt(SO_REUSEPORT): Protocol not available
>

Weird, that's the first time I've seen this one.

Well, I'll add it to the list of things to test on 64-bit.  I wonder
if the arguments to setsockopt() are incorrect, since it does take a
pointer to some memory for the socket option.

So, anyways, in response this thread, I've just done what I probably
should have done originally.  I changed the liblo website to list 0.26
as the stable release and 0.27 as a testing release.

Steve

On Tue, Jul 9, 2013 at 8:54 AM, Stephen Sinclair <rad...@gm...>wrote:

> On Tue, Jul 9, 2013 at 4:56 PM, Felipe Sateler <fsa...@gm...> wrote:
>
> > This would mark all functions not explicitly listed in the global
> > scope as local to the shared library, and thus unavailable for client
> > applications.
>
> Right.  I mean, we do something similar with the .def file in windows,
> as you point out.  I just haven't seen anything other projects using
> such an approach on Linux, I figured it wasn't necessary.  Perhaps it
> would be a cautious step though.
>
> > If versioning is desired, a more complex symbol map is required. More
> > info on this is in the DSO howto by Ulrich Drepper
> >
> > http://www.akkadia.org/drepper/dsohowto.pdf
>
> Thanks.
>
> > I could enable the test suite in debian, I didn't realize there was
> > one. This should give at least some free testing. However, the
> > testsuite seems to run forever, is it that long or is there a bug?
>
> That's a bug, it should be fixed in the master branch now.
>
> Steve
>
>
Not to change the subject, but FYI, this is what I get running testlo in
git master on my 64-bit machine:

[snip]

liblo server error 9912 in /: Invalid message received (expected)
Reply received from osc.udp://127.0.0.1:16673/
Reply received from osc.udp://127.0.0.1:16673/

test run not completed
liblo test FAILED
liblo server error 92 in setsockopt(SO_REUSEPORT): Protocol not available

On Tue, Jul 9, 2013 at 8:51 AM, Stephen Sinclair <rad...@gm...>wrote:

>
> >
> > Perhaps I haven't been clear enough. I don't know the cause of the
> breakage.
> > This is the situation:
> >
> > When liblo 0.27, myself and several distro packagers tried it. I was
> excited
> > about the possible performance improvements. However, when liblo 0.27 was
> > installed, the OSC functionality stopped working in every program on the
> > system that used it--they all had to be recompiled against 0.27 in order
> to
> > work. Now, you can call that what you will, and it's true that I never
> > investigated the issue thoroughly enough to get to the bottom of it. If
> not
> > an ABI change, it certainly had the same effect as one.
>
> Okay, but this seems like an expected cycle for me.  I put out a
> release, distro maintainers test it, and then report back that it's ok
> for inclusion.  If it's _not_ ok, I hope they have the sense not to
> include it and instead report some bugs upstream, which is what's
> happening now.  I'll fix them and put out 0.28, and everything is
> dandy.  In the future I'll use RCs for this purpose.  I didn't think
> it worth it this time since all tests checked out for me, which was
> obviously a mistake.
>
> So I am not that put off by what's happening now, but I only wish
> people wouldn't take it as a bad sign, but rather as a normal part of
> the development cycle.  Calling it an RC would have made this clear.
>
> What I did take exception to was only that there was apparently a big
> discussion about the release on a separate mailing list and the first
> I've heard of it is after the software has been removed from the
> project.  (Why? If 0.26 was working fine, just keep it, and report the
> bugs upstream.. communication, people!)
>
> By the way, what performance improvements are you referring to? I
> don't recall including anything about performance improvements in the
> release notes.
>

Not doing a DNS lookup every time the message source address is checked
would be a performance improvement. I thought I saw that in the release
notes.

Anyway, that is what I did (I'm still running 0.26 personally). As to the
comments on forums you don't read...  Well, everybody has an agenda. And
sometimes a forum has a lower barrier to entry than a sourceforge
bugtracker. FWIW I started getting more and better bug reports when I
created an account on github.com, but it's always gonig to be a struggle to
get people (even other developers) to jump those hurdles.


>
> > I apologize for not bringing it to everyone's attention sooner--I figured
> > that since the problem was quite obvious it was either intentional or
> would
> > be noticed quickly. I maintain too much software of my own to be able to
> > spent a whole lot of time debugging other projects.
>
> It was only "quite obvious" if it actually triggered on your system.
> I guess my particular testing platform didn't trigger this bug, or my
> testing methodology was not good enough.
>
> Anyways, mostly my testing consisted of "make test".  I also used
> "icheck".  I admittedly didn't do a lot of "install distro X and
> replace the liblo binary" kind of testing.  This takes time and
> resources, which I don't have.
>
> Steve
>

Yeah. It could just be another 32-bit vs 64-bit issue. /me misses
sourceforge's compile farm. I believe ubuntu has some automated test
systems available now and I heard that opensuse just came out with
something similar. Might be worth looking into. I too have had my fair
share of frustration with packagers not reporting problems upstream, but
we're all busy people.

On Tue, Jul 9, 2013 at 4:56 PM, Felipe Sateler <fsa...@gm...> wrote:

> This would mark all functions not explicitly listed in the global
> scope as local to the shared library, and thus unavailable for client
> applications.

Right.  I mean, we do something similar with the .def file in windows,
as you point out.  I just haven't seen anything other projects using
such an approach on Linux, I figured it wasn't necessary.  Perhaps it
would be a cautious step though.

> If versioning is desired, a more complex symbol map is required. More
> info on this is in the DSO howto by Ulrich Drepper
>
> http://www.akkadia.org/drepper/dsohowto.pdf

Thanks.

> I could enable the test suite in debian, I didn't realize there was
> one. This should give at least some free testing. However, the
> testsuite seems to run forever, is it that long or is there a bug?

That's a bug, it should be fixed in the master branch now.

Steve

On Tue, Jul 9, 2013 at 4:51 PM, J. Liles <mal...@gm...> wrote:
>
>
>
> On Tue, Jul 9, 2013 at 7:07 AM, Felipe Sateler <fsa...@gm...> wrote:
>>
>> Hi,
>>
>> On Tue, Jul 9, 2013 at 5:33 AM, Stephen Sinclair <rad...@gm...>
>> wrote:
>> > On Mon, Jul 8, 2013 at 6:23 PM, J. Liles <mal...@gm...> wrote:
>> >> On Mon, Jul 8, 2013 at 9:14 AM, Felipe Sateler <fsa...@gm...>
>> >> wrote:
>> >>> On Mon, Jul 8, 2013 at 11:41 AM, J. Liles <mal...@gm...>
>> >>> wrote:
>> >>
>> >> In that case I would like to point out that this ABI breakage was
>> >> noticed by myself and others who did not use the function in question.
>> >> I assumed it was intentional (there had been some back and forth on
>> >> this list at the time about changing some functions in the API). The
>> >> incompatibility actually caused a  minor flame on LinuxMusicians.com
>> >> when some individuals took the ABI breakage as an excuse to denigrate
>> >> all things OSC. FYI, I have a 64-bit system.
>> >
>> > Oh that's great.  As maintainer of the package this really grinds my
>> > gears.  I waited 4 years between releases trying to make sure it was
>> > perfect, but basically between myself and Camille, we are the only
>> > ones actually regularly testing the master branch, and I simply don't
>> > have a server farm of every architecture under the sun to test on.  A
>> > little more testing help from the OSC community would be appreciated
>> > rather than people silently dismissing the whole thing when I make a
>> > small mistake.
>>
>> I wouldn't put much weight in unsubstantiated claims by random people.
>> A private symbol dissapearing is hardly a binary compatibility issue,
>> but rather a "I want my program to be fragile" issue on the part of
>> depending applications.
>
>
> Excuse me, but I am not a random person, I am the author of 4 large
> application that use liblo, and I am responsible for the inclusion of liblo
> in almost a dozen more.

No worries, I am certainly interested in fixing bugs as they appear.
Currently I can't since I have to date been unable to test on a 64-bit
machine and reproduce this problem.

Hopefully I'll be able to soon enough.


>> > Anyways, in the future I'll be sure to do release candidates instead
>> > of just putting it out there directly, since obviously my testing
>> > approach is not thorough enough.  As a maintainer, it's annoying to
>> > have several bug reports come in immediately *after* a long-awaited
>> > release, instead of before.
>>
>> I'm sorry I didn't report before, but the usual excuse of lack of time
>> applies.

I understand.  To be clear, I'm not all that upset, but it's just
that, knowing that liblo is used in many applications, I really did
try to ensure that this was a fairly stable release.  I was very
surprised to learn about some problems it caused, since there had been
basically no reports of problems from the master branch on the mailing
list.

Beyond my own testing and reports from other people using the master
branch, I don't know what I could have done to avoid this, other than
testing everyone else's software.  However, the same excuses apply
here in reverse... lack of time, and more importantly, not having the
interest to compile a bunch of dependencies to get an experimental
version of someone elses software working just so I can test mine.

>> > By the way, on the technical side, I don't see how omitting an
>> > internal function from the ABI would cause breakage?  Can someone
>> > explain this to me?
>>
>> It can only cause breakage if someone decided to use said undocumented
>> function. So, either the program was asking for breakage, or nothing
>> bad happens.
>>
>
>
> But that is not the reality.
>
> Perhaps I haven't been clear enough. I don't know the cause of the breakage.
> This is the situation:
>
> When liblo 0.27, myself and several distro packagers tried it. I was excited
> about the possible performance improvements. However, when liblo 0.27 was
> installed, the OSC functionality stopped working in every program on the
> system that used it--they all had to be recompiled against 0.27 in order to
> work. Now, you can call that what you will, and it's true that I never
> investigated the issue thoroughly enough to get to the bottom of it. If not
> an ABI change, it certainly had the same effect as one.

Okay, but this seems like an expected cycle for me.  I put out a
release, distro maintainers test it, and then report back that it's ok
for inclusion.  If it's _not_ ok, I hope they have the sense not to
include it and instead report some bugs upstream, which is what's
happening now.  I'll fix them and put out 0.28, and everything is
dandy.  In the future I'll use RCs for this purpose.  I didn't think
it worth it this time since all tests checked out for me, which was
obviously a mistake.

So I am not that put off by what's happening now, but I only wish
people wouldn't take it as a bad sign, but rather as a normal part of
the development cycle.  Calling it an RC would have made this clear.

What I did take exception to was only that there was apparently a big
discussion about the release on a separate mailing list and the first
I've heard of it is after the software has been removed from the
project.  (Why? If 0.26 was working fine, just keep it, and report the
bugs upstream.. communication, people!)

By the way, what performance improvements are you referring to? I
don't recall including anything about performance improvements in the
release notes.

> I apologize for not bringing it to everyone's attention sooner--I figured
> that since the problem was quite obvious it was either intentional or would
> be noticed quickly. I maintain too much software of my own to be able to
> spent a whole lot of time debugging other projects.

It was only "quite obvious" if it actually triggered on your system.
I guess my particular testing platform didn't trigger this bug, or my
testing methodology was not good enough.

Anyways, mostly my testing consisted of "make test".  I also used
"icheck".  I admittedly didn't do a lot of "install distro X and
replace the liblo binary" kind of testing.  This takes time and
resources, which I don't have.

Steve

On Tue, Jul 9, 2013 at 10:51 AM, J. Liles <mal...@gm...> wrote:
>
>
>
> On Tue, Jul 9, 2013 at 7:07 AM, Felipe Sateler <fsa...@gm...> wrote:
>>
>> Hi,
>>
>> On Tue, Jul 9, 2013 at 5:33 AM, Stephen Sinclair <rad...@gm...>
>> wrote:
>> > On Mon, Jul 8, 2013 at 6:23 PM, J. Liles <mal...@gm...> wrote:
>> >> On Mon, Jul 8, 2013 at 9:14 AM, Felipe Sateler <fsa...@gm...>
>> >> wrote:
>> >>> On Mon, Jul 8, 2013 at 11:41 AM, J. Liles <mal...@gm...>
>> >>> wrote:
>> >>
>> >> In that case I would like to point out that this ABI breakage was
>> >> noticed by myself and others who did not use the function in question.
>> >> I assumed it was intentional (there had been some back and forth on
>> >> this list at the time about changing some functions in the API). The
>> >> incompatibility actually caused a  minor flame on LinuxMusicians.com
>> >> when some individuals took the ABI breakage as an excuse to denigrate
>> >> all things OSC. FYI, I have a 64-bit system.
>> >
>> > Oh that's great.  As maintainer of the package this really grinds my
>> > gears.  I waited 4 years between releases trying to make sure it was
>> > perfect, but basically between myself and Camille, we are the only
>> > ones actually regularly testing the master branch, and I simply don't
>> > have a server farm of every architecture under the sun to test on.  A
>> > little more testing help from the OSC community would be appreciated
>> > rather than people silently dismissing the whole thing when I make a
>> > small mistake.
>>
>> I wouldn't put much weight in unsubstantiated claims by random people.
>> A private symbol dissapearing is hardly a binary compatibility issue,
>> but rather a "I want my program to be fragile" issue on the part of
>> depending applications.
>
>
> Excuse me, but I am not a random person, I am the author of 4 large
> application that use liblo, and I am responsible for the inclusion of liblo
> in almost a dozen more.

I'm sorry. The above was way too aggressive and wasn't intended (and
the "randomness" wasn't meant as an insult). What I mean is that
unsubstantiated claims of "doesn't work" are useless, and therefore
one shouldn't waste time and effort into looking into them. Decent bug
reports are worth looking into. "Doesn't work!!!11" is not. IMO, of
course, and YMMV.


>> >
>> > Anyways, in the future I'll be sure to do release candidates instead
>> > of just putting it out there directly, since obviously my testing
>> > approach is not thorough enough.  As a maintainer, it's annoying to
>> > have several bug reports come in immediately *after* a long-awaited
>> > release, instead of before.
>>
>> I'm sorry I didn't report before, but the usual excuse of lack of time
>> applies.
>>
>> >
>> > By the way, on the technical side, I don't see how omitting an
>> > internal function from the ABI would cause breakage?  Can someone
>> > explain this to me?
>>
>> It can only cause breakage if someone decided to use said undocumented
>> function. So, either the program was asking for breakage, or nothing
>> bad happens.
>>
>
>
> But that is not the reality.
>
> Perhaps I haven't been clear enough. I don't know the cause of the breakage.
> This is the situation:
>
> When liblo 0.27, myself and several distro packagers tried it. I was excited
> about the possible performance improvements. However, when liblo 0.27 was
> installed, the OSC functionality stopped working in every program on the
> system that used it--they all had to be recompiled against 0.27 in order to
> work. Now, you can call that what you will, and it's true that I never
> investigated the issue thoroughly enough to get to the bottom of it. If not
> an ABI change, it certainly had the same effect as one.

This looks more like a true implementation bug rather than a binary
compatibility issue. Missing symbols, invalid parameters, and other
binary issues would cause the hosts to crash, not silently drop OSC
functionality.

--

Saludos,
Felipe Sateler

On Tue, Jul 9, 2013 at 7:45 AM, Stephen Sinclair <rad...@gm...> wrote:

> I indeed missed the change to lo_server_recv_raw_stream() from the
> ABI, it's an oversight and I take responsibility, but perhaps it's
> more something I'm misunderstanding than a real oversight; I still
> don't get why an *internal* function being removed would cause a
> problem.

I found about this change by a semi-automated tool that scans the
exported symbols in a shared library. From the POV of that tool, all
exported symbols are public.

> For the record, I did check binary compatibility using the
> "icheck" utility, but usage of this tool requires passing in the
> header files.  Since lo_server_recv_raw_stream() does not appear in
> the header files, it was not reported as problematic.

If a function is exported in the library but is not in the headers,
then for someone to use it they would need to actively work against
what the library intended. I say they get what they ask for when the
function is removed.

That said:

>
> Although I guess I should have not made this function static, it
> should not have been in the public ABI in the first place.  That said,
> sometimes in C there are internal functions that do get exposed to the
> ABI just because they need to be shared between modules.  (An example
> is lo_address_resolve(), which is in one case called from send.c)
>
> If anyone knows good practice to avoid this kind of issue please let me know.

Yes, as long as all functions remain in the same shared library (eg,
send.c ends up in liblo, not in a test program, which seems to be the
case).
In linux, by default all symbols are exported in a shared library. In
windows, it is the opposite (don't know about mac, but it is likely
like linux). This is the reason liblo already includes a .def file to
export the public symbols in windows. In linux, gcc can be told to
behave in a similar way to windows (although more powerful, as it also
allows versioning). Short version of such a version map:

{
    global:
        lo_address_errno;
        lo_address_errstr;
        // etc etc
    local:
        *;
};

This would mark all functions not explicitly listed in the global
scope as local to the shared library, and thus unavailable for client
applications.

If versioning is desired, a more complex symbol map is required. More
info on this is in the DSO howto by Ulrich Drepper

http://www.akkadia.org/drepper/dsohowto.pdf


>
>
>> - members of this list, please try to give more feedback and be more reactive when a release date is coming.  It does not cost a lot to spend 15 minutes getting the latest code and running the tests.
>
> Additionally, if anyone knows good resources to test things let me
> know.  One problem is that at the moment "testlo" is a bit of a mess.
> But even the unit testing can't catch all the problems.  One
> suggestion to me was to check reverse dependencies in debian to find
> what programs depend on liblo, and test them all.  But I'm afraid that
> doing this, particularly on multiple architectures and operating
> systems, is a bit more work than I can manage to put in.  I have no
> choice but to depend on the community for testing, and I can't fix
> what isn't reported.

I could enable the test suite in debian, I didn't realize there was
one. This should give at least some free testing. However, the
testsuite seems to run forever, is it that long or is there a bug?
Currently it seems to have deadlocked:
./test_bidirectional_tcp
0xce0008.server fd: 3
0xce0008.receiving1..
0xce0ee8.sending thread
0xce0008.done receiving1
0xce0008.receiving2..
0xce0008./test, from TCP::
0xce0008.address fd: -1
0xce0ee8.message sent
0xce0ee8.sending thread waiting
0xce0008.reply sent
0xce0008.done receiving2


And it hangs there.

--

Saludos,
Felipe Sateler