Re: mark_object crash in 22.1 and latest CVS (as of tonight)

[Kalman Reti]

On Nov 16, 2007 12:28 PM, martin rudalics <address@hidden> wrote:
> Do you mean in code wrapped in `save-match-data' you delete some region
> of text containing a marker of the saved match-data.

It isn't in my code, it is in the shell-command function in simple.el, but
essentially this is correct.

Most of the guts of calling the subprocess to generate the output is
inside save-match-data; I don't know exactly what path results in the
markers' getting on the undo list, but if I create a new macro
save-match-data-noevaporate that is identical to the original
minus the 'evaporate argument to set-match-data and use that
inside of shell-command instead of the original, my crash goes away.

>                                                                               
>   Thus
> record_marker_adjustment puts an entry on `buffer-undo-list' referencing
> that marker.  The unwindforms of `save-match-data' call `set-match-data'
> with evaporate/reseat non-nil, which calls free_marker and subsequently
> free_misc.  mark_object - operating from `buffer-undo-list' - detects
> that the object is already free and aborts.

There is something which causes this not to happen all the time which
I have not yet found.  If you are lucky and this "something" happens before the
next GC, all is well.  I'd been doing exactly the same sorts of shell operations
in elisp functions for years before encountering one big enough to have a 100%
chance of being unlucky.  It does many hundreds of shell operations (perhaps
even thousands, I haven't counted them) taking many minutes.

>
> If I understand correctly, this means that either markers used for
> saving match-data should not go to `buffer-undo-list' or the "evaporate"
> option set by `save-match-data' is inherently broken.
>

My suspicion is that the save-match-data was intended to be wrapped around
very short local uses of markers, not the collection of arbitrary amounts of
shell stdout output...