[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The infamous "Pure PUTPROP Twice" bug
- To: (BUG LISP) at MIT-MC
- Subject: The infamous "Pure PUTPROP Twice" bug
- From: RLB at MIT-MC (Richard L. Bryan)
- Date: Thu, 11 Dec 80 01:00:00 GMT
- Original-date: 10 DEC 1980 2000-EST
JONL and I just found why this one happens.
You push your property name P onto PUTPROP, hoping that
while loading up your system, putprops under P will be PURCOPYed, hence
sharable among users of your system. While loading, symbol S gets
a P property, and later gets another. After purify/suspend/restart,
you find that symbol S has randomness under its P property -- randomness
which changes from GC to GC.
PUTPROP is buggy. The first time it tries to put a P on S, it finds
that there is no P there. It checks for P memq in PUTPROP, finds it so,
purcopies the property value, purconses cells to go in the plist of S,
and splices into the plist.
The second time, PUTPROP finds P is on S. It DOES NOT check for P
on PUTPROP, DOES NOT purcopy the property value, merely HRRMing it
into the plist cell. The plist cell is typed in ST as needing to
become pure, but of course won't actually become read-only until PURIFY
runs. Now we have the screw of impure sexp pointed to only by
not-marked-from pure sexp. It will get collected (and its cells later
reused) next gc.
PUTPROP should check P for memq in PUTPROP and purcopy the value,
if necessary, in all cases. It will need to remember if purcopying
took place so it will know to purcons new plist cells if it finds
that they are needed.
(1) This is entirely unrelated to write-in-pure-page trapping of attempts
by putprop to alter existing pure plist cells.
(2) Surgery on PUTPROP has not been performed.