From fnaumann@mail.cs.uni-magdeburg.de Mon Jan 12 04:23:27 2004 Message-ID: <004701c3d8ba$eea2f700$da0863d9@blaszak> Reply-To: "Konrad Kokoszkiewicz" From: "Konrad Kokoszkiewicz" To: References: <001001c3d812$9508aad0$0b0a63d9@blaszak> Subject: Re: [MiNT] Problem Date: Mon, 12 Jan 2004 04:18:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-Virus-Scanned: by amavisd-new X-MIME-Autoconverted: from 8bit to quoted-printable by antyk.obta.uw.edu.pl id i0C3JRZd005787 Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: draco@obta.uw.edu.pl Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prinz.cs.uni-magdeburg.de id i0C3NPn28470 >> new = (BASEPAGE *)Pexec(7L, (void *)flags, "", 0L); > > I haven't found any doc on Pexec(7). Pexec(7) is just the same as Pexec(5), except that the second argument are prgflags. It was first implemented in TOS 3.0, and MiNT has it too. > Maybe programmer/man/man2/Pexec.2 should be updated. Yes, it should :-) >> static short child_global[16]; > > The use of GEMlib seems good. So we have a problem, why it doesn't work. > BTW, just a stupid question: is the static array child_global[] part > of the child memory ? Or is it owned by the parent only ? This is a part of the parent BSS. However, Pexec(104) guarantees that the child and parent share one common TEXT/DATA/BSS (the child is a "thread" of the parent), and only the basepage/stack are separate. I did some experiment, and changed the child code into something simpler: static short childarg; static void child_proc(BASEPAGE *bp) { short ca; Cconws("Child: started up\r\n"); ca = childarg; Cconws("Child: argument OK\r\n"); Pause(); Pterm(ca); } Now, THIS DOES'NT WORK EITHER. So the problem does not seem to be AES-related at all. This is what appears on the screen: Child: started up Child: argument OK pid 58 (child): MEMORY VIOLATION: type=private RW=w AA=867FBE PC=85428A BP=866000 or (yes, results are different): Child: started up pid 213 (child): MEMORY VIOLATION: type=private RW=w AA=867FD2 PC=854270 BP=866000 Notice that the access address (AA) that causes the bus error, is $17FE/$1FD2 (6142/8146) bytes bigger, than the child's basepage address (BP). Since the child's basepage is shrunk earlier to $2000 (8192) bytes by the parent, then it seems that the fault occurs, when the child accesses it's own stack. If I don't overlook anything, then it seems that something is seriously screwed here. -- CVV Konrad M.Kokoszkiewicz, http://draco.atari.org ** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur. ** Taka to już natura pospólstwa, albo służalczo się płaszczy, ** albo bezczelnie się panoszy. (T. Liuius XXIV, 25).