go@mist.CS.ORST.EDU (Gary Oliver) (07/28/90)
Bruce Evans (brucee@runxtsa.runx.oz.au) points out a BAD bug in my shared text implementation. A task being ptraced needs to have sharing disabled or else you will clobber all other incarnations of that program. Rather than implement a patch kit for my version, I am going to wait. Bruce is testing a different version of shared text submitted by another 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) and wait. Sorry for any problems this may have caused you all. Hope Bruce gets his out soon :-). Gary Oliver go@jacobs.cs.orst.edu
brucee@runxtsa.runx.oz.au (Bruce Evans) (07/31/90)
>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)