From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8588 Path: news.gmane.org!not-for-mail From: u-uy74@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread_getattr_np() vs explicit runtime loader Date: Wed, 30 Sep 2015 17:43:37 +0200 Message-ID: <20150930154337.GC13149@example.net> References: <20150920063909.GO12087@example.net> <20150920163405.GK17773@brightrain.aerifal.cx> <20150920172237.GR12087@example.net> <20150920182728.GM17773@brightrain.aerifal.cx> <20150920193033.GS12087@example.net> <20150920194132.GO17773@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1443627847 16139 80.91.229.3 (30 Sep 2015 15:44:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 15:44:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8600-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 30 17:44:07 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZhJY6-0001J7-Su for gllmg-musl@m.gmane.org; Wed, 30 Sep 2015 17:44:06 +0200 Original-Received: (qmail 32657 invoked by uid 550); 30 Sep 2015 15:44:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32633 invoked from network); 30 Sep 2015 15:44:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fripost.org; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=20140703; t=1443627830; x=1445442231; bh=bjGJGcQ+2 VT3BGGuan34TOJE8/9m119g1b6H6PwqsCo=; b=ZF84G5l2jL/j/2nHb/rZPKD7P jJjejyBpWBtE4J/sAWJv5EfQfytrwoZ7A3LWDdt7bw9sZ9eUnPCsHJau9MHxzK+H nESGqpdhv/XUndkzPh0zrRpPL1sHXxbFnBXEa7Wi1DxBIa4sgMxQ55nDI77MwKjv yOlokaODk9LYfzyIq8= X-Virus-Scanned: Debian amavisd-new at fripost.org Content-Disposition: inline In-Reply-To: <20150920194132.GO17773@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8588 Archived-At: On Sun, Sep 20, 2015 at 03:41:32PM -0400, Rich Felker wrote: > I don't see anywhere this code has any interacton whatsoever with how > the program was loaded. So I suspect plain old undefined behavior if > the crash depends on how it was loaded. > > You can easily test this if you have got say a jv-convert binary of > > gcc-5.2.0, dynamically linked with musl and run this binary via the > > explicit loader. Yours and mine environments are different but I would > > not be surprised if the binary crashes for you too. An update: The observed crashes were both very consequent and confusing for the debuggers which I tried. Then I had to put this on wait. Now when I returned to testing, the crashes do not appear any longer. This is most probably related to the fact that the host has been rebooted meanwhile (to the same kernel, ~ 3.18.11). Note that I saw the crashes earlier with binaries from gcc-5.1.0 too, i.e. this was a consistent pattern under quite some time, with different builds, on many occasions. No similar problems with other programs during the same time, nor any problem if using the implicit loader. So either this was an artifact of a "somehow specifically corrupt" kernel or this is some assumption which blows up, given a certain state (not necessarily corrupt) of the kernel. I believe more in the latter (is there a contract about how/where the kernel shall allocate the thread stacks?). I still think that the crashes are caused by errors while guessing the stack placement in pthread_getattr_np(), simply because of the kernel doing something else than usual. Unfortunately, in practical terms: no misbehaviour to analyze for the moment. Rune