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

[Pirmin Walthert <pirmin.walthert@wwcom.ch>]

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