From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13904 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeffrey Walton Newsgroups: gmane.linux.lib.musl.general Subject: Re: Asterisk 16 segmentation fault Date: Thu, 28 Feb 2019 16:32:20 -0500 Message-ID: References: <20190228202751.GB31965@darth.lan> <20190228211517.GC23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="156040"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Sebastian Kemper To: musl@lists.openwall.com Original-X-From: musl-return-13920-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 28 22:32:55 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gzTIV-000eRh-Ik for gllmg-musl@m.gmane.org; Thu, 28 Feb 2019 22:32:55 +0100 Original-Received: (qmail 11651 invoked by uid 550); 28 Feb 2019 21:32:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11621 invoked from network); 28 Feb 2019 21:32:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=i8t6XBake1JOCBhZ9xYISIlxHmUJE70itAmzLx4bq5w=; b=FTaPEztv53pErL8uHH08IdbIaTa7FzmxSkHaF6JkVaJFeaTB++9xn2JP4Xvv/w7weO aL/75R+AHB2hL5lt+OchnS7l8okXz1lq3sye+Lj/1E9y9xHMyGd/cy968WEShkNY7d67 MYnxEYEiToRyKhPqZibabUTPHu1z7444peuINtXFVlOk2Wf576/bfzf7u+8rPTL3AMj9 8jwLTJ4q8w9b75c1ZJVqKJbZqS59TWLXX9sD1xOeD6gPhLTdyfCDvxbcrk6u4WTv6fNk IVuPROjxuCLgBzOByA/mjQZ0C5k6ME1rQLhTFr928QUYKbsclWuVLHDbnWpyxEp4h9Ev 2oTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=i8t6XBake1JOCBhZ9xYISIlxHmUJE70itAmzLx4bq5w=; b=Eb6XTYA5w6p7fiAYuJXVsOULHLWz5NTzy+WDK6vvBbHupjBjGlqwNbmCrQ7BH8IAeu ex2QC8yzh5GHdtf4/oGnGity7FPDD/HD0vqcgQWMZd+kPwhBkPyRxGI8KtdPS7YjCU98 DF+9+7E+a1vPcO8BdPwQtalv7izGeGMtU21/nU/6NRzTrJylzx/8XAnOQrzRTfHVVefa bWZu2txKLkUB9oo58MMWzPL5rJTH7mypTCBJ08/JSEjgRU8G/A60HS+bhz5nXr5ICgVB 0eJI+fbtRXG2EYiX1GPbvWF6n4ctF/VXJUxWJsqtY/8y9/TwDha9CeAizmVtLxtEBBw0 2E0g== X-Gm-Message-State: APjAAAV4pEmC8WNdjpR978w+Hn/ZHYtRX+8JYNC7SVg2dXj2s3p9AtxO 0yeYuBbl7i7GfAElHUFi3c3DKjdIJUcYGu8WdZgZgiVQ X-Google-Smtp-Source: APXvYqxs5yoxO9zGor0xDKsMCXNFt8h6yRdnIDaJrbnqRN6OOdSy9X8sPHGjCsQVjgxsigG8TdCB/vZtXmecaP+2RfQ= X-Received: by 2002:a02:a88b:: with SMTP id l11mr807030jam.54.1551389560488; Thu, 28 Feb 2019 13:32:40 -0800 (PST) In-Reply-To: <20190228211517.GC23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13904 Archived-At: On Thu, Feb 28, 2019 at 4:15 PM Rich Felker 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