From mint-bounce@lists.fishpool.fi Tue Jan 26 04:41:39 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=L2vxJGhY6mA3Pg+yOlKi8C0HRaXtRmaSSbwrA7NrBiI=; b=xPgO/1nv/Wb0anFYH2lCfEHhPjyx2Hrr+gGE6EPHu+QhKwEj+2fo5zLcIU5WV8LJSJ bhivNGjVOIUUqDe8KdIjCwxL8fVPh168QsfyrEMDlnk4tYCaatn1sjCCtBnJceZS92mT gSoUWzLVNnl4XJU6ycyYnb0L2ZB8ALy/hhldc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KMrPLbeegs6bQUlGcjmEvCQiz1vE/Ydpxuwatw3a1JCwqT0jD/tCQ2q2xzjtCkFqyM fCK0NUjzDzHeU6GyiKBJJF+a6hgmnT6NdHojCaNJUzhvJ732fe0HO+oHfq/86SkKgpVs lX01OLxOjvWcrA4uJoY1aizeY18hMQT3p3vV8= MIME-Version: 1.0 In-Reply-To: <4B5EB4B9.9080807@freesbee.fr> References: <420195.6969.qm@web27401.mail.ukl.yahoo.com> <201001241235.58825.jflemaire@skynet.be> <4B5CB531.1010806@free.fr> <4B5CC2EB.5060603@lutece.net> <4B5E1890.8080002@chello.nl> <4B5EB4B9.9080807@freesbee.fr> Date: Tue, 26 Jan 2010 10:39:15 +0100 Message-ID: Subject: Re: [MiNT] windom and gcc4 From: Miro Kropacek To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= Cc: mint@lists.fishpool.fi Content-Type: multipart/alternative; boundary=000325555bf22b5379047e0e0fb7 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: miro.kropacek@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: --000325555bf22b5379047e0e0fb7 Content-Type: text/plain; charset=ISO-8859-1 > Does ldg->close() respect the GCC ABI, clobbering only d0/d1/a0/a1 ? I > hope... > As I said, ldg->close() does nothing, it points to libshare_exit() and it has empty body. I think I know where's the problem -- it's, surprisingly :), png.ldg itself -- I tried to do this exit code right after allocation/pexec and it gave me no violation. I disabled unloading of png.ldg but no mem.ldg and still no violation. That png.ldg allocation routine points back to libldg so no problem here either (else mem.ldg would suffer from this bug, too). So logical conclusion in my opinion is there's some memory corruption inside png.ldg's functions for loading/depacking png images (i.e. they corrupt its internal static 'LDG' structure which contains our problematic pointers to base page, envp etc), I try to replace them with dummy malloc (100000) calls (i.e. zWeather will load random, but allocated, pixels instead of icons) and if this will work, I'm sure the bug is there. But we're getting quite offtopic, so much attention for Zorro's tool here in mintlist... ;-) Hopefully, tonight I will catch that stupid bug and will be able to send full patch to Zorro. -- MiKRO / Mystic Bytes http://mikro.atari.org --000325555bf22b5379047e0e0fb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
Do= es ldg->close() respect the GCC ABI, clobbering only d0/d1/a0/a1 ? I hop= e...
As I said, ldg->close() does nothing, it points to lib= share_exit() and it has empty body. I think I know where's the problem = -- it's, surprisingly :), png.ldg itself -- I tried to do this exit cod= e right after allocation/pexec and it gave me no violation. I disabled unlo= ading of png.ldg but no mem.ldg and still no violation. That png.ldg alloca= tion routine points back to libldg so no problem here either (else mem.ldg = would suffer from this bug, too). So logical conclusion in my opinion is th= ere's some memory corruption inside png.ldg's functions for loading= /depacking png images (i.e. they corrupt its internal static 'LDG' = structure which contains our problematic pointers to base page, envp etc), = I try to replace them with dummy malloc (100000) calls (i.e. zWeather will = load random, but allocated, pixels instead of icons) and if this will work,= I'm sure the bug is there. But we're getting quite offtopic, so mu= ch attention for Zorro's tool here in mintlist... ;-)

Hopefully, tonight I will catch that stupid bug and wil= l be able to send full patch to Zorro.

--
MiKRO / Mystic= Bytes
http://mikro.atari.org
--000325555bf22b5379047e0e0fb7--