[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8nZEw5wvXq-99S9WsJh3pPDHxpP8d2-eXTBe+GYbhfqXw@mail.gmail.com>
Date: Thu, 28 Feb 2019 16:32:20 -0500
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Cc: Sebastian Kemper <sebastian_ml@....net>
Subject: Re: Asterisk 16 segmentation fault
On Thu, Feb 28, 2019 at 4:15 PM Rich Felker <dalias@...c.org> wrote:
>
> On Thu, Feb 28, 2019 at 09:27:51PM +0100, Sebastian Kemper wrote:
> >
> > I'm trying to update Asterisk 15 to 16 on OpenWrt. It's apparently not
> > easy %-).
> >
> > ...
> It looks like they expect resource_being_loaded to be 0 if the dlopen
> succeeds; assuming the intent is that some constructor in the loaded
> library sets it to 0, this is only valid for the first open. I'm
> guessing they've introduced some new plugin architecture that's not
> compatible with dlopen being permanent like it is in musl. The right
> way to fix this is probably to get rid of the constructors and instead
> have an explicit init function that their loader finds with dlsym and
> calls after dlopen succeeds. It looks like they also have support for
> building the modules builtin to the main program, rather than loading
> them by dlopen; this may be able to work around the problem.
>
> I think they have a lot of bugs and misunderstandings in this area.
> For instance, this commit is completely bogus:
>
> https://github.com/asterisk/asterisk/commit/23aa20bf209d
I'd hazard a guess that they are experiencing Static Initialization
Order Fiasco problems with their C++ objects. No fun...
The last time I checked (several years ago), Asterisk also had a load
of UBSan findings. At the time they were not performing regular
testing with -fsanitize=undefined. It caused a lot of problems for me
during acceptance testing. That may have changed, though.
Jeff
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
