erroneous auto-save-list file

erroneous auto-save-list file

[Stephen Berman]

A couple of days ago, Emacs crashed (an abort due to a since fixed bug),
and when I restarted it and typed M-x recover-session, the latest
.saved* file in auto-save-list only contained one file and its
auto-saved backup, though two other files also contained auto-saved
backups, and these were still in their directory, so I could recover
them.  I don't recall seeing this before, i.e., current auto-saved files
not being listed in the latest auto-save-list file.  Moreover, the
timestamps of the not listed auto-saved files were later than the
timestamp of the file that was listed.  Is this consistent with the
auto-save system or was something amiss, and if the latter, does anyone
have an ideas?

This was with GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version
2.12.0) of 2007-11-01 on escher.

Steve Berman

Re: erroneous auto-save-list file

[Richard Stallman]

    A couple of days ago, Emacs crashed (an abort due to a since fixed bug),
    and when I restarted it and typed M-x recover-session, the latest
    .saved* file in auto-save-list only contained one file and its
    auto-saved backup, though two other files also contained auto-saved
    backups, and these were still in their directory, so I could recover
    them.

This could happen due to a crash inside do_auto_save.
Is that what happened?

Re: erroneous auto-save-list file

[Stephen Berman]

On Thu, 08 Nov 2007 23:13:07 -0500 Richard Stallman <rms@gnu.org> wrote:

>     A couple of days ago, Emacs crashed (an abort due to a since fixed bug),
>     and when I restarted it and typed M-x recover-session, the latest
>     .saved* file in auto-save-list only contained one file and its
>     auto-saved backup, though two other files also contained auto-saved
>     backups, and these were still in their directory, so I could recover
>     them.
>
> This could happen due to a crash inside do_auto_save.
> Is that what happened?

Maybe.  The abort was due to a bug in the GTK+ tool bar code, which I
reported and Jan D. quickly fixed.  I suppose it is possible that
do_auto_save was being executed when the abort occurred, is it?  When
the initial abort occurred, resulting in the erroneous auto-save-list
file, Emacs was not running under gdb, but, as I wrote in my bug report
about the abort, even reproducing it under gdb yielded no backtrace, why
I don't know.  (The abort locked up my desktop and I could unlock it
only by killing the emacs process, after which, when I tried to get a
backtrace, gdb just said "Cannot access memory at address 0x8321b6c".)

Steve Berman

Re: erroneous auto-save-list file

[Richard Stallman]

      When
    the initial abort occurred, resulting in the erroneous auto-save-list
    file, Emacs was not running under gdb, but, as I wrote in my bug report
    about the abort, even reproducing it under gdb yielded no backtrace, why
    I don't know.

That could be a serious problem in GDB.  It would be good to talk
with GDB developers about how to investigate it.  Since the bug's
cause is known, they could focus on figuring out why GDB fails
to give a backtrace.

Re: erroneous auto-save-list file

[Stephen Berman]

On Fri, 09 Nov 2007 21:59:32 -0500 Richard Stallman <rms@gnu.org> wrote:

>       When
>     the initial abort occurred, resulting in the erroneous auto-save-list
>     file, Emacs was not running under gdb, but, as I wrote in my bug report
>     about the abort, even reproducing it under gdb yielded no backtrace, why
>     I don't know.
>
> That could be a serious problem in GDB.  It would be good to talk
> with GDB developers about how to investigate it.  Since the bug's
> cause is known, they could focus on figuring out why GDB fails
> to give a backtrace.

I've had a fruitful exchange about this on the gdb-devel list, and it
turns out gdb does give a backtrace.  I had been able to get it because
I had already killed the emacs process, which was the only way to
release my desktop after emacs aborted.  Michael Snyder explained it
like this:

>> In a nutshell, your emacs process has a lock on a shared 
>> resource (the X keyboard-and-mouse "focus").  It is intended
>> to keep that lock only briefly, but while in posession of the
>> lock, it aborts.
>> 
>> Normally an abort would result in the freeing of the lock, 
>> but since gdb stops the emacs process from exiting, the lock
>> is not freed, resulting in a deadlock when some other process
>> (eg. xterm) needs the lock.
>> 
>> This is a problem, but a normal and predictable one.
>> GDB cannot tell when a debugged process is in posession 
>> of a lock that will cause other processes to deadlock, 
>> and it has no way of freeing such locks.

He suggested starting gdb in a virtual console and attaching the emacs
process to this.  After emacs aborted under X, I switched to the virtual
console and was able to get a backtrace.[1] So there's no problem here
with gdb and since Jan D. had already fixed the bug which caused Emacs
to abort, this issue can be declared closed.

Steve Berman

Footnotes: 
[1]  The backtrace was not very informative, containing lines like this:
	#5  0xb7c7b1c1 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
	#6  0x085c2d00 in ?? ()
This may be because the shared libraries installed on my system are
stripped.

Re: erroneous auto-save-list file

[Richard Stallman]

Thanks for following up on the GDB issue.