🚀 go-pugleaf

In article <7225@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes:
> >Francois Rouaix <rouaix@inria.inria.fr> 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.