Re: Tramp with global-auto-revert-mode.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I also made emacs crash with tramp + global-auto-revert-mode.

> And I have studied the cause a little further and found at least one
> reason for the crash -- trying to mark a Lisp_Misc_Free object, most
> likely resulting from freeing a marker which is still present on
> some undo list.

> I have installed a fix for this; I don't know if it has any
> bad effects, but at least it solves the crash for me.

Well, it makes it "legal" to have a live Lisp_Misc_free object, which is at
least odd and might lead to further problems.

But more importantly, Fgarbage_collect has code that traverses the undo
lists and removes entries that contain unmarked markers, which should make
sure the problem you describe doesn't happen.  Obviously that code is not
100% successful at it, but rather than hide the problem we might want to
track it down further to see what's really going on.

Looking at the code, I see one case where things could go awry:
1) mark buffer -> mark the undo_list, skipping markers
2) coming from somewhere else, mark a cons cell who happens to also be
   on the undo_list we marked in step 1 and whose car is a marker:
   because the cons cells were already marked, we won't look at the marker.
   Also the code in Fgarbage_collect will remove the cons cell from the
   undo_list but that will not remove it from the other list, so it will
   stay and be turned into a reachable Lisp_Misc_Free.

Another thing I notice is that we do mark_stack and xg_mark_data after
cleaning up the undo_lists, so if any undo_list gets marked from mark_stack
or xg_mark_data we will leave the unmarked markers and turn them info
Lisp_Misc_Free.  I've just installed a fix for this last problem (although
it's not a very likely scenario so I don't expect it fixes the problem
we're seeing).

I don't have a fix for the first yet problem yet (which is also somewhat
unlikely, but less so, so maybe it is the problem we're seeing).


        Stefan