From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10547 Path: news.gmane.org!.POSTED!not-for-mail From: u-uy74@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: "non-float" malloc (was: incompatibility between libtheora/mmx and musl) Date: Sun, 2 Oct 2016 12:59:50 +0200 Message-ID: <20161002105950.GM28325@example.net> References: <20160913180649.GN16436@example.net> <20160913204304.GY15995@brightrain.aerifal.cx> <20160914103253.GO16436@example.net> <20160914112400.GS1280@port70.net> <20160914140450.GQ16436@example.net> <20160914142842.GZ15995@brightrain.aerifal.cx> <20160914144145.GT1280@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1475406033 12926 195.159.176.226 (2 Oct 2016 11:00:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Oct 2016 11:00:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10560-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 02 13:00:29 2016 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.84_2) (envelope-from ) id 1bqeVH-0001dE-7P for gllmg-musl@m.gmane.org; Sun, 02 Oct 2016 13:00:19 +0200 Original-Received: (qmail 3363 invoked by uid 550); 2 Oct 2016 11:00:18 -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 3331 invoked from network); 2 Oct 2016 11:00:16 -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=1475406005; x=1477220406; bh=EiaT67S4D CxyGqN+W+ql29OzW7nLRD+v1OGB4emN5Cw=; b=iXcHViLnM7I/z2HLBGR1xA7iK 8iNDCQ7z72item2jYWC6yTp/6xJQf4mYBThzcyjRrmnwUCugEtJMCgoqCkAFq1aj tbvPzlVKZR/H1qmRN4EpvKpuzrnWkNp2atIZzj5ShTMJf4Z3BMPWbWScRuWT8kq2 gCuHcYl4KAY6/o6xNw= X-Virus-Scanned: Debian amavisd-new at fripost.org Content-Disposition: inline In-Reply-To: <20160914144145.GT1280@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:10547 Archived-At: Hello Szabolcs, On Wed, Sep 14, 2016 at 04:41:45PM +0200, Szabolcs Nagy wrote: > this might be an issue: > musl uses float instructions in malloc, > if mmx needs different fpu state and > they don't change it back for a malloc > call that can corrupt the heap. > > to test this, try to use the 'non-float bin index' > code in musl from here: > http://port70.net/~nsz/musl/malloc.c Thanks again for the solution to the libtheora mystery. Now I have reported the same issue affecting ffmpeg, it contains quite a bit of simd assembler code and assumed until now among others that malloc() never uses floating point. Hopefully a fix is on the way there. For the time being, to have a working ffmpeg build, I tried to use your "non-float" malloc. Unfortunately this leads to a segfault when used with the explicit runtime loader, because brk() happily grows over the dynamic loader's data. The modified variant of the malloc code seems to not apply the traverses_stack_p() check. I guess as long as you want to keep the special malloc.c you would like it to be robust. Would you mind adding the brk()/stack overlap checking to this variant of the code? Regards, Rune