all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* erroneous auto-save-list file
@ 2007-11-08 22:57 Stephen Berman
  2007-11-09  4:13 ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2007-11-08 22:57 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: erroneous auto-save-list file
  2007-11-08 22:57 erroneous auto-save-list file Stephen Berman
@ 2007-11-09  4:13 ` Richard Stallman
  2007-11-09  8:23   ` Stephen Berman
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2007-11-09  4:13 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

    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?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: erroneous auto-save-list file
  2007-11-09  4:13 ` Richard Stallman
@ 2007-11-09  8:23   ` Stephen Berman
  2007-11-10  2:59     ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2007-11-09  8:23 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: erroneous auto-save-list file
  2007-11-09  8:23   ` Stephen Berman
@ 2007-11-10  2:59     ` Richard Stallman
  2007-11-15  8:51       ` Stephen Berman
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2007-11-10  2:59 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

      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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: erroneous auto-save-list file
  2007-11-10  2:59     ` Richard Stallman
@ 2007-11-15  8:51       ` Stephen Berman
  2007-11-16  4:28         ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2007-11-15  8:51 UTC (permalink / raw)
  To: emacs-devel

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: erroneous auto-save-list file
  2007-11-15  8:51       ` Stephen Berman
@ 2007-11-16  4:28         ` Richard Stallman
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2007-11-16  4:28 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

Thanks for following up on the GDB issue.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-11-16  4:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-08 22:57 erroneous auto-save-list file Stephen Berman
2007-11-09  4:13 ` Richard Stallman
2007-11-09  8:23   ` Stephen Berman
2007-11-10  2:59     ` Richard Stallman
2007-11-15  8:51       ` Stephen Berman
2007-11-16  4:28         ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.