From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13648 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Infinite loop in malloc Date: Fri, 25 Jan 2019 22:49:29 +0100 Message-ID: <20190125214929.GE23924@voyager> References: <20190125151350.GB20330@r> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="64688"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13664-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 25 22:50:30 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 1gn9Mq-000GeS-D8 for gllmg-musl@m.gmane.org; Fri, 25 Jan 2019 22:50:28 +0100 Original-Received: (qmail 12187 invoked by uid 550); 25 Jan 2019 21:50:25 -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 12162 invoked from network); 25 Jan 2019 21:50:24 -0000 Content-Disposition: inline In-Reply-To: <20190125151350.GB20330@r> X-Provags-ID: V03:K1:xdpEmejCVGMUFbORhQ6ks4kjIUP4EDbS9+xgsD2usUrOOCZI94f XMiuLk8wp7NDZregXcjgosW6FJCnKf1nwnnQ34LrkUFCZhZQxO0Aew+KZxDMk+EU8Dt6VWv Hx+PthNaxcTqMVxBbpxi8BLVA7YCgA/XdO2RN81vaHjv9CdGFA8c2Z3okrya2+2gCZTEP0A T83ZPQ84jEIao1N6JVUVQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:4yfII/Q/Jsc=:ZXCb07XpnFnpAj0BycskXS RlLkSNzVdfSSQeyV34tZma4AjWr83Fa2a9S1cWWJsk609m4USOB+WMDmVn1OGxQuLI93O+xEn lh4pB+0HRni10Aq81m0kgAwUQX51eDblQdnHReUmrHdxLOPosNtA4iHKPWe/fhA12r/k/y4BP xlW4wZ+OuFnNMcvoVWh+movX07ucYgKSZLvkFkBMcHkUFEIYocG7odpnaHPm1dGyjpPvU73+C iZZ+IEWHcEbHJDh9FAZOQ27NL27JeNnQ6PC7rSPJv6vnw6fKCDuR9vcqrPSDgEk941fjbGejm GCuI0VrOcUc3IFiNtTlNswod5XA/T0fF0nrXeinVwUFz78YQn3qmQSEouovF3BzAlaaU8LRGk f+MzVhn4NRiHaIgEXqSv+0PcrPi1YKlW+DzihH/U9EC6jac17FKsFqaT9lsb8BsZap7L2GWOJ xqCbTfGuR2oEPDLRkcjpNFRfiDou0eCGvCzLFOQpnv5rLed0yJTEWJ+upNngy83W3nPyIlDPF JgtDgboaYvyzN6CJ9xqBXfn6GWWD7rcWjpfJZ3LXFZDzChUDTPkyMwCiLEfmXyuxS9Doj23fG 26bnSXzVizuQB8WcXYZyqgu4ZbuOjRlofqyslqcnH9SKWjJchN59FrrPEHDUx0kqS1dX/bJiM POQhZVXcdNazXOD6ldZZDkMVq9MCqPrFJmv1gFLVHwoAR3+8xXg/Y7T+PVWAlqpuOeULKGqam VQvVH7GzjyTazhxoTkmxhAaJafFXYB+52b03thU7PtP8qs+CVmcWI/atytys8da7g++b78VA Xref: news.gmane.org gmane.linux.lib.musl.general:13648 Archived-At: On Fri, Jan 25, 2019 at 10:13:50AM -0500, r yang wrote: > Examining the value in gdb: > (gdb) printf "%X\n", mask > 204701 > > The bin head points to the bin itself so this condition is never met: > c = mal.bins[j].head; > if (c != BIN_TO_CHUNK(j)) { ... } > > Examining the values in gdb: > (gdb) printf "%X\n", mal.bins[j].head > 62337FC0 > (gdb) printf "%X\n", (struct chunk *)((char *)(&mal.bins[j].head) - (2*sizeof(size_t))) > 62337FC0 Wait, isn't that an invalid state? The bins are circular doubly linked lists; the head points back to itself only when the list is empty. But the binmap is only set for non-empty bins. At least in the single-threaded case. So, if the bit is 1, then it was never deleted. So either arm's a_and_64() is b0rken, or the last chunk removed from the smallest bin was invalid, and didn't trigger the a_and_64(). Or does anyone have a better idea? Ciao, Markus