From mint-bounce@lists.fishpool.fi Mon Jan 25 17:41:01 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=4knHJL+6nHyL7KtKUtUHuHVvI/zvblkRxrIlK2mt9dY=; b=sx3HNdUZeOsaz1n67di2PV2VlH7MxAgrohgOz8knBa3kSvRt5/8KXtbeEm+/c46cTb FARUcGRxmMDrFwnK7dZrPMM1Ug4s1r/Fv3D4DLB2TYN3DlF0WJq1q+Scj7nLosBtzG0Q BjwSwnW8qvZx2B3NMphaKwLscwVNFDEeQRXTQ= 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=sy/fVw4riihAhUCJI7ZMJOrzmjhwYUKNf3upF6skGOG4grGFBEX83RqiUjmq9HWwu6 Z0jVsIrljRdauB+5DYwWsRWyXGinowPrsLWbf51EDvb2xEo7OGHFHrhcJa5VslaPVZZN WsmEq51RAXN1Byvlfj9l9eRyHb/Snd0rG34iY= MIME-Version: 1.0 In-Reply-To: <4B5E1890.8080002@chello.nl> 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> Date: Mon, 25 Jan 2010 23:39:08 +0100 Message-ID: Subject: Re: [MiNT] windom and gcc4 From: Miro Kropacek To: Henk Robbers Cc: mint@lists.fishpool.fi Content-Type: multipart/alternative; boundary=00032555843a642dd3047e04d6ba 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: --00032555843a642dd3047e04d6ba Content-Type: text/plain; charset=ISO-8859-1 > What if ldg points to something in the freed area? > Maybe ldg itself is the pointer the the Malloc'd area. > Maybe baspag is the first member of the struct. > In which case ldg and ldg->baspag point to the same address :-) > This is how it works (short version): LDG* ldg = NULL; BASPAG* module = NULL; char offsetxt[24]; sprintf(offsetxt,"OFFSETLDG=%ld%c%c",(long)&ldg,'\0','\0'); module = (BASPAG *)Pexec( 3, path, NULL, offsetxt); Pexec( 4, NULL, module, NULL); ldg -> baspag = module so, we pass pointer to LDG* to ldg module which should be loaded... second Pexec executes this code (between those two Pexec's is some code but unrelated to our problem), i.e. our NULL value in 'ldg' becomes some address as the part of executions is allocation of memory and storing the pointer to the given address. Next, Compendium says parent process (caller) should free env and basepage space when exit, what is our code: if( ldg->close) (*ldg->close)(); Mfree( ((BASPAG *)ldg->baspag)->p_env); Mfree( ldg->baspag); ldg->baspag = NULL; as far as I understood, ldg->close() does nothing (it went down to libshare and there was empty body) and then we see what's next: freeing memory allocated by OS so this must be OK. I think the only place (except some obscure situation) where the bug may be is the allocation routine inside ldg module -- but I didn't take a deep look yet. -- MiKRO / Mystic Bytes http://mikro.atari.org --00032555843a642dd3047e04d6ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0
What if ldg points to something in the freed area?
Maybe ldg itself is the pointer the the Malloc'd area.
Maybe baspag is the first member of the struct.
In which case ldg and ldg->baspag point to the same address :-)
This is how it works (short version):

LDG* ldg =3D NULL;
= BASPAG* module =3D NULL;
char offsetxt[24];
sprintf(offsetxt,"OF= FSETLDG=3D%ld%c%c",(long)&ldg,'\0','\0');
module =3D (BASPAG *)Pexec( 3, path, NULL, offsetxt);
Pexec( 4, NU= LL, module, NULL);
ldg -> baspag =3D module

so, we pass pointe= r to LDG* to ldg module which should be loaded... second Pexec executes thi= s code (between those two Pexec's is some code but unrelated to our pro= blem), i.e. our NULL value in 'ldg' becomes some address as the par= t of executions is allocation of memory and storing the pointer to the give= n address.

Next, Compendium says parent process (caller) should free env and basep= age space when exit, what is our code:

=A0if( ldg->close) (*ldg-&= gt;close)();
=A0 =A0 =A0 =A0Mfree( ((BASPAG *)ldg->baspag)->p_env);
=A0 =A0 =A0 =A0Mfree( ldg->baspag);
=A0 =A0 =A0 =A0ldg->baspag =3D NULL;

as far as I understood, ldg= ->close() does nothing (it went down to libshare and there was empty bod= y) and then we see what's next: freeing memory allocated by OS so this = must be OK.

I think the only place (except some obscure situation) where the bug ma= y be is the allocation routine inside ldg module -- but I didn't take a= deep look yet.


--
MiKRO / Mystic Bytes
http://mikro.atari.org
--00032555843a642dd3047e04d6ba--