gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Pirmin Walthert]

Hello

First thing: http://git.musl-libc.org/cgit/musl/commit/?id=6476b8135760
659b25c93ff9308425ca98a9e777 seems to break Asterisk compatibilty.
Asterisk crashes on every startup while loading modules. Using musl-git 
combined with the latest dynlink.c version before this commit works
fine. (1.1.16 has some startup crashes as well because of the bug fixed
with 27b3fd68f67b674440d21ea7ca5cf918d2e1559f).

Second: I'm currently debugging a strange memory corruption problem and
have just had a look at the gethostbyname2.c code:

I was wondering: why is it safe to do free(h) on the initial run when
*h has not been 

        static struct hostent *h;
        size_t size = 63;
        struct hostent *res;
        int err;
        do {
                free(h);

Best regards,

Pirmin

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Pirmin Walthert]

(has not been initialized)

Am Donnerstag, den 24.08.2017, 13:39 +0200 schrieb Pirmin Walthert:
> Hello
> 
> First thing: http://git.musl-libc.org/cgit/musl/commit/?id=6476b81357
> 60
> 659b25c93ff9308425ca98a9e777 seems to break Asterisk compatibilty.
> Asterisk crashes on every startup while loading modules. Using musl-
> git 
> combined with the latest dynlink.c version before this commit works
> fine. (1.1.16 has some startup crashes as well because of the bug
> fixed
> with 27b3fd68f67b674440d21ea7ca5cf918d2e1559f).
> 
> Second: I'm currently debugging a strange memory corruption problem
> and
> have just had a look at the gethostbyname2.c code:
> 
> I was wondering: why is it safe to do free(h) on the initial run when
> *h has not been 
> 
>         static struct hostent *h;
>         size_t size = 63;
>         struct hostent *res;
>         int err;
>         do {
>                 free(h);
> 
> Best regards,
> 
> Pirmin

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Shiz]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]


>> Second: I'm currently debugging a strange memory corruption problem
>> and
>> have just had a look at the gethostbyname2.c code:
>> 
>> I was wondering: why is it safe to do free(h) on the initial run when
>> *h has not been
>> 
>>        static struct hostent *h;
>>        size_t size = 63;
>>        struct hostent *res;
>>        int err;
>>        do {
>>                free(h);
>> 
>> Best regards,
>> 
>> Pirmin

h is defined as having static storage, as such its initial
value is NULL. free(NULL) is valid.

- Shiz

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Pirmin Walthert]

Am Donnerstag, den 24.08.2017, 14:47 +0200 schrieb Shiz:
> > > Second: I'm currently debugging a strange memory corruption
> > > problem
> > > and
> > > have just had a look at the gethostbyname2.c code:
> > > 
> > > I was wondering: why is it safe to do free(h) on the initial run
> > > when
> > > *h has not been
> > > 
> > >        static struct hostent *h;
> > >        size_t size = 63;
> > >        struct hostent *res;
> > >        int err;
> > >        do {
> > >                free(h);
> > > 
> > > Best regards,
> > > 
> > > Pirmin
> 
> h is defined as having static storage, as such its initial
> value is NULL. free(NULL) is valid.
> 
> - Shiz

You're right, thanks for pointing that out.

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Timo Teras]

On Thu, 24 Aug 2017 13:39:08 +0200
Pirmin Walthert <pirmin.walthert@wwcom.ch> wrote:

> First thing:
> http://git.musl-libc.org/cgit/musl/commit/?id=6476b8135760
> 659b25c93ff9308425ca98a9e777 seems to break Asterisk compatibilty.
> Asterisk crashes on every startup while loading modules. Using
> musl-git combined with the latest dynlink.c version before this
> commit works fine. (1.1.16 has some startup crashes as well because
> of the bug fixed with 27b3fd68f67b674440d21ea7ca5cf918d2e1559f).

I am using asterisk 14 just fine on Alpine linux with current musl git
master. We needed few patches though. Maybe those help you too:
https://git.alpinelinux.org/cgit/aports/tree/main/asterisk

Though, some issues might be relevant to specific modules.

Timo

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Pirmin Walthert]

Hi Timo

Thanks, we use Asterisk 13 since months on about 100 VM's with musl, we
have only one strange issue that leads to a crashes from time to time,
especially when using PickupChan. Somehow I couldn't reproduce the
crash when using only hostnames in FROM headers that I'd put into
/etc/hosts (but as it is hard to reproduce anyway it's not sure whether
this is really the reason). However I've seen that some pjsip functions
used in the multihomed module (in asterisk 13 at least) are using
gethostbyname (not gethostbyname_r). 

I'm waiting for feedback from the asterisk team whether it's possible
that several threads are using the multihomed code at the same time.

Asterisk 14 has some changes in the resolver, so maybe that's the
reason why Asterisk 14 isn't affected.

Best regards,

Pirmin

Am Donnerstag, den 24.08.2017, 15:58 +0300 schrieb Timo Teras:
> On Thu, 24 Aug 2017 13:39:08 +0200
> Pirmin Walthert <pirmin.walthert@wwcom.ch> wrote:
> 
> > First thing:
> > http://git.musl-libc.org/cgit/musl/commit/?id=6476b8135760
> > 659b25c93ff9308425ca98a9e777 seems to break Asterisk compatibilty.
> > Asterisk crashes on every startup while loading modules. Using
> > musl-git combined with the latest dynlink.c version before this
> > commit works fine. (1.1.16 has some startup crashes as well because
> > of the bug fixed with 27b3fd68f67b674440d21ea7ca5cf918d2e1559f).
> 
> I am using asterisk 14 just fine on Alpine linux with current musl
> git
> master. We needed few patches though. Maybe those help you too:
> https://git.alpinelinux.org/cgit/aports/tree/main/asterisk
> 
> Though, some issues might be relevant to specific modules.
> 
> Timo

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Rich Felker]

On Thu, Aug 24, 2017 at 01:39:08PM +0200, Pirmin Walthert wrote:
> Hello
> 
> First thing: http://git.musl-libc.org/cgit/musl/commit/?id=6476b8135760
> 659b25c93ff9308425ca98a9e777 seems to break Asterisk compatibilty.

This commit should not affect code that didn't error-out from missing
symbols before. Is it possible you have a module Asterisk is trying to
load, which it previously silently (or with a warning you didn't
notice) failed to load, but which now loads and tries to run despite
having unresolved symbols? One thing you could try is changing all
dlopen calls in Asterisk from RTLD_LAZY to RTLD_NOW and see if the
problem goes away. If so that doesn't necessarily mean Asterisk is
broken; it could be a bug in lazy binding on musl's side. But it will
help narrow down the cause.

Rich

Re: gethostbyname2.c / 6476b8135760659b25c93ff9308425ca98a9e777 breaking asterisk 13 compatibility

[Pirmin Walthert]

Hi Rich

I think I've found a problem in the way Asterisk is using pjsip today
(or in pjproject itself: I'm not sure whether the function in question
just shouldn't be used from several threads at the same time or whether
they accidentialy didn't make it threadsafe): There is a possibility
that several threads could use the same pjproject function at the same
time which uses gethostbyname... This can cause memory corruptions in
lots of different ways.

As the startup issues I had were as well crashes while allocation
memory it's not impossible that the fix I've made for pjsip will solve
this problem as well... Will let you know.

Best regards,

Pirmin



Am Donnerstag, den 24.08.2017, 12:17 -0400 schrieb Rich Felker:
> On Thu, Aug 24, 2017 at 01:39:08PM +0200, Pirmin Walthert wrote:
> > Hello
> > 
> > First thing: http://git.musl-libc.org/cgit/musl/commit/?id=6476b813
> > 5760
> > 659b25c93ff9308425ca98a9e777 seems to break Asterisk compatibilty.
> 
> This commit should not affect code that didn't error-out from missing
> symbols before. Is it possible you have a module Asterisk is trying
> to
> load, which it previously silently (or with a warning you didn't
> notice) failed to load, but which now loads and tries to run despite
> having unresolved symbols? One thing you could try is changing all
> dlopen calls in Asterisk from RTLD_LAZY to RTLD_NOW and see if the
> problem goes away. If so that doesn't necessarily mean Asterisk is
> broken; it could be a bug in lazy binding on musl's side. But it will
> help narrow down the cause.
> 
> Rich