Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!rex!ames!uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!metro!ipso!runxtsa!brucee
From: brucee@runxtsa.runx.oz.au (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: a bug in shared text
Message-ID: <2080@runxtsa.runx.oz.au>
Date: 31 Jul 90 09:42:46 GMT
References: <19561@orstcs.CS.ORST.EDU>
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 69

>text implementation.  A task being ptraced needs to have sharing disabled
>or else you will clobber all other incarnations of that program.
>...
>person and this version will not have that problem.  My advice (temporarily)
>would be to ensure you make a private copy of a program being debugged
>or better yet, remove my shared text code altogether (safer and more secure)

I wouldn't go as far as deleting the shared text code in most cases, since
mdb for the PC is not widely available. Anyone trying to run a *secure*
multiuser Minix system should remove it, because ptrace can be used to
break in without mdb.

>Sorry for any problems this may have caused you all.  Hope Bruce gets his
>out soon  :-).

I've got common I&D "working". The text segment has to be copied, except
perhaps for an old copy with no current users. There is no way to stop
anyone modifying the master copy (on a 286 or 68K, unlike for separate I&D
on a 286), so sharing is only suitable for trusted programs.

THere seems to be a bad (old) bug in MM that causes memory to be freed more
than once. This caused trouble with my version of shared text, and may
affect Gary's version too. I don't know why it hasn't caused trouble with
the standard MM, but have noticed that MM works remarkably well with a
corrupted hole list. The enclosed diff might fix it. Not guaranteed since
it was edited out of a larger diff for my version.

*** dist/forkexit.c	Tue Jul 31 19:20:27 1990
--- forkexit.c	Mon Jul 30 04:55:32 1990
***************
*** 155,161 ****
  
!   /* How to terminate a process is determined by whether or not the
!    * parent process has already done a WAIT.  Test to see if it has.
!    */
!   rmp->mp_exitstatus = (char) exit_status;	/* store status in 'mproc' */
  
    if (mproc[rmp->mp_parent].mp_flags & WAITING)
--- 152,161 ----
  
!   if (rmp->mp_flags & HANGING) {
! 	/* Parent was not waiting last time, so cleanup was delayed. */
! 	if (mproc[rmp->mp_parent].mp_flags & WAITING)
! 		cleanup(rmp);	/* now parent is waiting */
! 	return;			/* don't free things again */
!   }
  
+   rmp->mp_exitstatus = (char) exit_status;	/* store status in 'mproc' */
    if (mproc[rmp->mp_parent].mp_flags & WAITING)
***************
***************
*** 250,254 ****
   *     2. The process' parent has done a WAIT.
!  *
!  * It releases the memory, if that has not been done yet.  Whether it has or
!  * has not been done depends on the order of the EXIT and WAIT calls.
   */
--- 246,252 ----
   *     2. The process' parent has done a WAIT.
!  * Many of the process' possessions, in particlular its memory, are cleaned up
!  * elsewhere and may or may not already be gone, depending on the order of the
!  * EXIT and WAIT calls.  This routine only deals with the possessions that
!  * have to be returned to the parent: the parent's mproc index and the child's
!  * pid and exit+signal status.
   */
-- 
Bruce Evans
Internet: brucee@runxtsa.runx.oz.au    UUCP: uunet!runxtsa.runx.oz.au!brucee
(My other address (evans@ditsyda.oz.au) no longer works)