Re: frames vs. weak hash tables and garbage collection

[Joe Wells <jbw@macs.hw.ac.uk>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The reference from `values' is just due to the fact that you run
>>> `reproduce-bug' from M-: and that its return value contains the frame, so
>>> it's a rather unusual circumstance.
>
>> I'm confused.  The frame can only show up in values if it fails to be
>> garbage collected for another reason.
>
> Right.  In your case the reason is the recent events array.
>
>> Anyway, although I can see that the recent events array would be
>> enough to cause the problem, I'm not sure it is the only cause.
>
> Could be, but at least it matched the behavior I saw:
> if I hit a key 300 times, set `values' to nil, and call garbage-collect then
> the hash-table entry gets deleted (I modified your test case to make the
> hash-table global).
>
>>   (defun reproduce-bug ()
>>     [ ... new version of code deleted ... ]
>>     ... )
>
> No idea about this one, but it may very well be due to transient effects
> such as the fact that the stack is scanned conservatively, so there may
> still be a spurious pointer to the frame left over somewhere at the time you
> call `garbage-collect'.

It seems it is not the stack.  See below.

> Also the sit-for is enough to cause redisplay and execution of process
> filters, but I'm not convinced it's enough to cause the frame events to be
> added to the "recent events array", so maybe these will appear after the
> call to clear-this-command-keys.

Okay.  Using a recursive-edit seems to be enough:

  (defun reproduce-bug ()
    (let ((ht (make-hash-table :weakness 'key)))
      (let ((x
             (make-frame)
             ;;(get-buffer-create "xyzzy")
             ))
        (puthash x t ht)
        (delete-frame x)
        ;;(kill-buffer x)
        )
      ;; Give time for various frame related events to be handled, in
      ;; case this is needed.
      (recursive-edit)
      ;; There may be a reference to the frame in the array of recent
      ;; events, so we clear this array.
      (clear-this-command-keys)
      ;; In theory, the only reference to the new frame is now the key
      ;; in the hash table.  Because of the weakness, this key should
      ;; not keep the frame alive.
      (garbage-collect)
      ;; The hash table should now be empty.
      (let (l)
        (maphash (lambda (k v) (push (cons k v) l)) ht)
        l)))

Evaluate (reproduce-bug) and type C-M-c (exit-recursive-edit) in the
recursive edit, and it correctly returns nil.

(By the way, I tried doing

  (setq unread-command-events (append (kbd "C-M-c") nil))

just before the recursive edit, but that wasn't enough.  It needs to
have real user interaction.  I'm curious if there is some purely
programmatic way of simulating the effects of a recursive edit with
only C-M-c typed in it, because this would help in building test
cases.)

Conclusion:  There is no bug with garbage collection of deleted
frames, but merely the appearance of a bug, because the recent event
array keeps the frame alive for a while.

Thanks for tracking down the cause of the appearance of a bug!

-- 
Joe