From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12902 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: SIGSEGV and SIGILL at malloc/free on ARM926 Date: Tue, 5 Jun 2018 22:27:44 -0400 Message-ID: <20180606022744.GD1392@brightrain.aerifal.cx> References: <4067bdff-eaa2-4efc-8068-a6116a5e243e.xulu@allwinnertech.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1528251954 17515 195.159.176.226 (6 Jun 2018 02:25:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2018 02:25:54 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12918-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 06 04:25:49 2018 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 1fQO8y-0004SY-P9 for gllmg-musl@m.gmane.org; Wed, 06 Jun 2018 04:25:48 +0200 Original-Received: (qmail 11752 invoked by uid 550); 6 Jun 2018 02:27:57 -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 11721 invoked from network); 6 Jun 2018 02:27:56 -0000 Content-Disposition: inline In-Reply-To: <4067bdff-eaa2-4efc-8068-a6116a5e243e.xulu@allwinnertech.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12902 Archived-At: On Wed, Jun 06, 2018 at 09:35:06AM +0800, 徐露 wrote: > > On Tue, 5 Jun 2018 01:58:48 -0400, Rich Felker wrote: > >On Tue, Jun 05, 2018 at 11:24:34AM +0800, 徐露 wrote: > >> > >> Mon, 4 Jun 2018 05:41:29 -0400, Rich Felker wrote: > >> > Looks like classic double-free. > >> The program crashes randomly. If it is double free, it will may > >> crash at the same place or same time. > > > >Only if the program completely lacks any concurrency. If it's > >multithreaded, or if it's dealing with any external communications > >(pipes, network, etc.) that may be subject to timing differences, > >there is no reason to expect it to behave deterministically. > > > >> Besides, if the memory is freed before, the csize of this chunk > >> should be the same with next chunk's psize. > > > >Not necessarily. If the freed chunk was merged with neighboring free > >space, the bytes which were headers and footers at the time of free > >need not be headers and footers now. If they were not overwritten, > >they'll still have their old values but there's no reason to assume > >the old values are consistent at this point. > > > >> And the chunk's next and > >> prev pointer should point at . > > > >Not necessarily; they could point to the bin head at mal+xx or to > >other free chunks in the same bin. In the case of two frees in > >immediate succession (with no concurrency) you would expect to find > >the freed chunk at the start of its bin, but in general that need not > >be the case. > > Thank you for your prompt reply. I learned a lot from it. > > >> For example, the 3rd case. > >> #0 0x0045e320 in a_crash () at src/malloc/malloc.c:465 > >> #1 free (p=0x7b81e0) at src/malloc/malloc.c:465 > >> psize csize prev next > >> 0x7b81d8: 0x11 0x30 0x4 0x3d0504 > >> 0x7b81e8: 0x3d0268 0x0 0x0 0x0 > >> 0x7b81f8: 0x7b8210 0x0 0x0 0x0 > >> 0x7b8208: 0x31 0x40 0x60ed30 0x60ed30 > > > >Of these 4 lines, only the first and last look like it's likely that > >they are or were chunk headers. Assuming the 0x30 in the first line is > >correct, the second and third lines are just space inside the freed > >chunk. But then the fourth line wrongly has the chunk marked as > >in-use, and has another free chunk (of size 0x40) adjacent, which is > >inconsistent. > > > >In case there is any actual bug on our side, rather than just memory > >corruption by the application, can you fill us in on any additional > >details, especially whether the process is multithreaded? Knowing that > >would determine what sorts of further investigation might or couldn't > >be useful. > > ARM926 is a signle core processor, and the application is multi-threaded. > > I am sorry I sent several wrong mail to you. Perhaps I attached a large file. Yes, the list seems to have rejected the large attachment. I got the off-list cc's. I can't follow up right now but I'll see if I can tell later if it looks like it could be a bug on our side. Rich