[LispM] bug in hash-table-rehash?

[Scott L. Burson]

You may have found a bug.  Since rehashing hash tables is presumably a
frequent operation, and thus this code is likely to be well exercised, I
strongly suspect that in practice, hash tables never had nonempty leaders.

-- Scott


On Sun, Mar 11, 2018 at 4:24 PM, Greg Gilley <ggilley at gerg.org> wrote:

>
> This is in the MIT sys99 code and the Explorer code:
>
> ((null grow) (setq hash-table (follow-structure-forwarding hash-table))
>     (setf (hash-table-lock new-hash-table) (hash-table-lock hash-table))
>     (%blt-typed (%find-structure-leader new-hash-table)
> (%find-structure-leader hash-table)
> (%structure-total-size hash-table) 1)
>     (return-array (prog1 new-hash-table (setf new-hash-table nil)))
>     hash-table)
>
> In the function hash-table-rehash, if it didn’t grow the table (after a gc
> perhaps), then it copies the re-hashed table back to the original hash
> table.
>
> However, it doesn’t seem to copy the whole table. if I read the comments
> from the microcode (this is from sys99, but seems similar to the lmi
> microcode):
>
>
> ;;; Given the address of the base of a structure, return information on
> its size.
> ;;; Note that if given the address of an array header, the leader (if any)
> is
> ;;; not counted, but if given the address of the leader, the leader is
> ;;; counted.  I.e. nothing before the given address is counted.
> ;;; In the case of an RPLACD-forwarded list, the 2 words pointed to by the
> ;;; forwarding-pointer are counted, and the forwarding-pointer itself
> isn't.
>
> It looks as though it’s not copying the complete hash table over because
> it’s passing in the pointer to the hash-table and the not the hash-table
> leader.
>
> Anyone familiar enough with the code to confirm my diagnosis?
>
> Thanks,
>
> Greg
>
>
> _______________________________________________
> LispM mailing list
> LispM at tunes.org
> http://lists.tunes.org/mailman/listinfo/lispm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/lispm/attachments/20180311/b9532aef/attachment.html>