Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!inria!rouaix From: rouaix@inria.inria.fr (Francois Rouaix) Newsgroups: comp.sys.amiga.tech Subject: Re: UnLoadSeg() Summary: bug found ! Message-ID: <1367@inria.inria.fr> Date: 10 Jul 89 08:55:12 GMT References: <8907032258.AA16367@jade.berkeley.edu> <7225@cbmvax.UUCP> Organization: FR.A.U.G. Lines: 42 In article <7225@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > >Francois Rouaix in message <1364@inria.inria.fr> writes > >> I have a doubt on the possibility that UnLoadSeg() might > >> Wait() somewhere. Does anybody knows for sure ? > For overlaid modules it will Wait(). > >> callsys Forbid > >> * setup UnLoadSeg > >> callsys UnLoadSeg > >> moveq.l 0,d0 > >> rts > UnLoadSeg() has no knowlege of tasks (think about it). However, it > is safe to reference memory that has been freed under a Forbid() so long > as it isn't the first N (where N=8) bytes of the freed hunk. For seglists, > the first 8 bytes are the segment size and next segment BPTR, so the code/ > data isn't touched. Once you explicitly or implicitly break the Forbid > (via Permit or Wait()), the memory can be trashed. We (Jean-Michel Forgeas and I) think we finally found the reason of this guru. It has to do with nested Forbid()/Permit(). Forbid() and Permit() work by incrementing and decrementing a counter (TDNestCount (sp?)) which tells the scheduler if the task may be switched or not. Now if you write too much Permit() (ie more than Forbid()) in the code, then the value in the counter might get negative. A later Forbid() will then have NO effect. This is what happen in the code above (there is one superfluous Permit() in the init code of the task). Therefore, the callsys Forbid() does not prevent the process from being switched, although UnLoadSeg() does not Wait(). In some cases, the memory where the code resides is reallocated and trashed, invoking a 4 guru. Since this was so much pain to debug, I'll make a wish for 1.4 ! I want that Permit() checks the counter so that it can never get negative (one MOVE is enough...). (Note how it is similar to some Lisps that allow superfluous closing parenthesis) Much thanx to all people who helped in this battle against the guru, especially to Randell Jesup and Peter da Silva --Francois-- *- Francois Rouaix // We are all prisoners here, * *- rouaix@inria.inria.fr \X/ of our own device * *- SYSOP of Sgt. Flam's Lonely Amigas Club. (33) (1) 39-55-84-59 (Videotext) * Disclaimer: Opinions expressed are my own, not those of my employer.