From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8531 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread_getattr_np() vs explicit runtime loader Date: Sun, 20 Sep 2015 15:41:32 -0400 Message-ID: <20150920194132.GO17773@brightrain.aerifal.cx> References: <20150920063909.GO12087@example.net> <20150920163405.GK17773@brightrain.aerifal.cx> <20150920172237.GR12087@example.net> <20150920182728.GM17773@brightrain.aerifal.cx> <20150920193033.GS12087@example.net> 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 1442778117 4139 80.91.229.3 (20 Sep 2015 19:41:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Sep 2015 19:41:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8543-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 20 21:41:50 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 1ZdkUf-0005PA-Ep for gllmg-musl@m.gmane.org; Sun, 20 Sep 2015 21:41:49 +0200 Original-Received: (qmail 29884 invoked by uid 550); 20 Sep 2015 19:41:47 -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 29842 invoked from network); 20 Sep 2015 19:41:46 -0000 Content-Disposition: inline In-Reply-To: <20150920193033.GS12087@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8531 Archived-At: On Sun, Sep 20, 2015 at 09:30:33PM +0200, u-wsnj@aetey.se wrote: > On Sun, Sep 20, 2015 at 02:27:28PM -0400, Rich Felker wrote: > > Test program attached. It's just a very basic functionality check. > > Thanks. > > I may be misinterpreting the code but I do not see where it tests > the condition > (http://man7.org/linux/man-pages/man3/pthread_getattr_np.3.html) > "Furthermore, if the stack address attribute was not set in the thread > attributes object used to create the thread, then the returned thread > attributes object will report the actual stack address that the > implementation selected for the thread." > > It seems to be this case which coincides with the crash. I'm not sure what you mean. Except for the main thread, the t->stack and t->stack_size fields store the correct values based on what was used at pthread_create time. The distinct code paths for caller-provided stack versus implementation-allocated stack already took place at pthread_create time. Moreover the case in your program is getting the stack for the main thread, not for another thread, so the code you're asking about is not even what's being executed. > I looked among others at > http://www.openwall.com/lists/musl/2013/03/31/5 > and > http://git.musl-libc.org/cgit/musl/commit/?id=5db951ef80cae8b627f95b995811bf916c069757 > > and still am unsure whether the assumptions hold while using > the explicit loader. 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. > > > > gcc? Have you used gdb to get a backtrace and see where the program > > > > actually crashes? > > > > > > Not yet, going to. Rebuilding gcc with '-g', this takes some time. > > > > Unless gcc is the program crashing I don't see why you need to rebuild > > gcc with -g... > > These _are_ several of the binaries of gcc-5.x which crash. It looks like > the ones which crash (java-related ones?) are using pthread_getattr_np() > while others do not. I did not though consequently check all of them. > > 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. I might get a chance to look later, but first thought: is jv-convert using boehm gc? I ask because boehm is one of the main users (iirc) of pthread_getattr_np and it's full of UB. It's possible that gcc 5 broke some of the things it's doing, or that they were already broken but didn't happen to crash before. I think boehm needs some patches to work safely on musl but maybe not anymore. Rich