From mint-bounce@lists.fishpool.fi Mon Jan 11 10:03:20 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WJ689CQj/YiyHLoFI59KucpiBo+P4wTZGs5STyMXEEI=; b=JPeANrb9P6r2lW+C4LD7epwC6/8ZSF+EBkr+0fX4NbcAH7hTt2KWVYL254phJ7vAA+ Y0NrPyf0CT0E6f/BJxEvhRtDyzQLQpyYJtdhE2eUdCtE/x9uQXgZJwgk64ktMEWIFVu8 towDtBmbYn/SaQNfkEYKPxWKDeMPNwc1Qi+oQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Y8GS+rtjKPAgD2mTcs2y1VxBKK9oHPeO92BD0dzIKRKs/mzxtiGpJAbwOQqJk8XUn+ 8W2pxmGFyROlKvkqgVybD0fu+rO0sOSJ7Z7JsYDT2z8ovOXEOZzPzj5BWTppwTzU6I4X mlWANQoIgnMB3XW7SP5YQlUtlVP1G7WszIfwM= Message-ID: <4B4B3CFC.9040504@freesbee.fr> Date: Mon, 11 Jan 2010 16:00:12 +0100 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mint@lists.fishpool.fi Subject: Re: [MiNT] malloc() bug ? References: <4B477F2C.4020503@freesbee.fr> <4B47BAC9.2080000@freesbee.fr> <4B47BBFB.2040206@atari-source.org> <11a6f2b11001102254s5bbca91am42472d701646ed2c@mail.gmail.com> <4B4AF146.7090603@freesbee.fr> <11a6f2b11001110444m665fcc8p11af912c7514686c@mail.gmail.com> <4B4B3333.4050802@atari-source.org> <4B4B344B.1060306@freesbee.fr> <4B4B3B51.9000605@freesbee.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Miro Kropacek wrote: > I'm not sure if you're right -- kernel has much more trace outputs, so > we can see some special condition has happened (for example allocation 1 > byte behind page boundary, N bytes long biggest available block, number > of block or anything else, I'm just guessing). But of course, debug > mintlib + debug kernel may be the best option. Do the MiNTLib malloc() call the kernel malloc every time ? I'm absolutely not sure about that. That looks like a problem in the malloc implementation in the MiNTLib. And it is quite complicated. -- Vincent Rivière