huge files in ~/.emacs.d/auto-save-list/

huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

I just deleted 2.7 GB (yes, you read that right) of files in the above
named directory.  Wow.  

The size and contents of 98% of the files in that directory look OK
(all less than 2K and are a series of pathnames, one per line).  Some
of the files, however, are really enormous.  They all start out OK,
but have complete garbage in them after a certain point.  Sometimes
mail messages.  Sometimes binary data.

I've seen this on several machines around here, and under several
users accounts, so it is not isolated to my .emacs/uid.

Anyone else seen this?  I found only one reference in google
(http://ww.telent.net/diary/2004/7/#4.78600) to the problem.  It's
rather hard to search using ".saves-", unfortunately.

I can easily write a cron job to clean up the problem, but it feels
like a pretty bad bug to me.

Kevin

Re: huge files in ~/.emacs.d/auto-save-list/

[Eli Zaretskii]

> Date: Mon, 21 May 2007 13:39:13 -0700
> From: Kevin Layer <layer@franz.com>
> 
> I just deleted 2.7 GB (yes, you read that right) of files in the above
> named directory.  Wow.  
> 
> The size and contents of 98% of the files in that directory look OK
> (all less than 2K and are a series of pathnames, one per line).  Some
> of the files, however, are really enormous.  They all start out OK,
> but have complete garbage in them after a certain point.  Sometimes
> mail messages.  Sometimes binary data.
> 
> I've seen this on several machines around here, and under several
> users accounts, so it is not isolated to my .emacs/uid.
> 
> Anyone else seen this?  I found only one reference in google
> (http://ww.telent.net/diary/2004/7/#4.78600) to the problem.  It's
> rather hard to search using ".saves-", unfortunately.
> 
> I can easily write a cron job to clean up the problem, but it feels
> like a pretty bad bug to me.

Thanks for reporting, but please provide the necessary details: the
OS, the Emacs version, the works (M-x report-emacs-bug RET will do
that for you).

FWIW, the largest file in my .emacs.d/auto-save-list/ directory is
13KB big, and it has no garbage in it.  There are 75 files there,
created during a year-long period.  This is (various pretests of)
Emacs 22.1 on MS-Windows XP SP2.

In general, if the garbled files were produced by a session that
crashed, that could explain the garbage: after all, Emacs is in deep
trouble when it crashes, and your description sounds like Emacs had
its memory badly trashed.  But I agree that it's a nasty problem that
should be tracked down.  The problem is, we cannot easily do that
without some kind of recipe for reproducing the problem.

Re: huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

Eli Zaretskii <eliz@gnu.org> wrote:

>> Thanks for reporting, but please provide the necessary details: the
>> OS, the Emacs version, the works (M-x report-emacs-bug RET will do
>> that for you).

emacs 21.3 for sure, perhaps emacs 22 (I've been using it a few months
and I can't remember if any of the big files were in that time
frame).  OS: a variety of Linux versions (FC 6, FC 5 for sure).

>> In general, if the garbled files were produced by a session that
>> crashed, that could explain the garbage: after all, Emacs is in deep
>> trouble when it crashes, and your description sounds like Emacs had
>> its memory badly trashed.  But I agree that it's a nasty problem that
>> should be tracked down.  The problem is, we cannot easily do that
>> without some kind of recipe for reproducing the problem.

Understood.

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    The size and contents of 98% of the files in that directory look OK
    (all less than 2K and are a series of pathnames, one per line).  Some
    of the files, however, are really enormous.  They all start out OK,
    but have complete garbage in them after a certain point.

What were the names of those files?

Re: huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

Richard Stallman <rms@gnu.org> wrote:

>>     The size and contents of 98% of the files in that directory look OK
>>     (all less than 2K and are a series of pathnames, one per line).  Some
>>     of the files, however, are really enormous.  They all start out OK,
>>     but have complete garbage in them after a certain point.
>> 
>> What were the names of those files?

Like this:

.saves-26656-gemini.franz.com~

There was nothing to distinguish them from all the "normal" files in
that directory.

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    .saves-26656-gemini.franz.com~

    There was nothing to distinguish them from all the "normal" files in
    that directory.

It would be good for a few people to study the code in fileio.c
which writes those files, and see if we can find a possible
explanation for these failures.

Could you look at the directory once each week to see
if more such failures have happened?  Maybe then you would
still remember whether Emacs had crashed.

I wonder, is the file ALL junk after a certain point?
Or is the junk inserted in the middle?

The existing code relies on an unwind-protect to close the stream.
Maybe something fails to run the unwind-protect.  Could you try
running with this change, and tell us if it prevents the problem?



*** fileio.c	22 Mar 2007 08:15:04 -0400	1.580
--- fileio.c	22 May 2007 14:23:20 -0400	
***************
*** 6021,6026 ****
--- 6021,6027 ----
  
    /* Prevent another auto save till enough input events come in.  */
    record_auto_save ();
+   fclose (stream);
  
    if (auto_saved && NILP (no_message))
      {

Re: huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

Richard Stallman <rms@gnu.org> wrote:

>> Could you look at the directory once each week to see
>> if more such failures have happened?  Maybe then you would
>> still remember whether Emacs had crashed.

I was thinking the same thing.

>> I wonder, is the file ALL junk after a certain point?
>> Or is the junk inserted in the middle?

I think I saw occasional lines that looked ok, but they were few and
far between the junk.

>> The existing code relies on an unwind-protect to close the stream.
>> Maybe something fails to run the unwind-protect.  Could you try
>> running with this change, and tell us if it prevents the problem?

I'm going to run for a while to see if the problem reoccurs with emacs
22.  If it does, I'll add the following change and test it.

>> *** fileio.c	22 Mar 2007 08:15:04 -0400	1.580
>> --- fileio.c	22 May 2007 14:23:20 -0400	
>> ***************
>> *** 6021,6026 ****
>> --- 6021,6027 ----
>>   
>>     /* Prevent another auto save till enough input events come in.  */
>>     record_auto_save ();
>> +   fclose (stream);
>>   
>>     if (auto_saved && NILP (no_message))
>>       {

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    >> I wonder, is the file ALL junk after a certain point?
    >> Or is the junk inserted in the middle?

    I think I saw occasional lines that looked ok, but they were few and
    far between the junk.

This is very important!  If junk is followed by valid lines,
that means the junk was output from inside the function that produces
the intended output.

So please check this carefully.  Are any of those files on backups?

    I'm going to run for a while to see if the problem reoccurs with emacs
    22.  If it does, I'll add the following change and test it.

Someone pointed out that that patch has problems; please don't try it
as written.

Anyway, it was meant to deal with the possibility that the problem
comes from writing into the stream after the end of the autosave.
If the junk is interspersed with the intended material, that's
a totally different kind of problem.

Re: huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

Richard Stallman <rms@gnu.org> wrote:

>>     >> I wonder, is the file ALL junk after a certain point?
>>     >> Or is the junk inserted in the middle?
>> 
>>     I think I saw occasional lines that looked ok, but they were few and
>>     far between the junk.
>> 
>> This is very important!  If junk is followed by valid lines,
>> that means the junk was output from inside the function that produces
>> the intended output.
>> 
>> So please check this carefully.  Are any of those files on backups?

I found a couple of bad files at home.  One is 1mb, the other 17mb.  I
use 21.4.1 on Linux (FC6) there.  There are definite good lines
interspersed in between the junk.  And often the good lines do not
start at the beginning of a line--I had to search for common pathnames
to find them.

Interestingly, some of the junk is from my +inbox (I use MH-E 8.0.3)
and sometimes the good lines near the +inbox junk are pathnames in my
inbox directory.  Other times it's just binary junk.

>>     I'm going to run for a while to see if the problem reoccurs with emacs
>>     22.  If it does, I'll add the following change and test it.
>> 
>> Someone pointed out that that patch has problems; please don't try it
>> as written.

Understood.

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    I found a couple of bad files at home.  One is 1mb, the other 17mb.  I
    use 21.4.1 on Linux (FC6) there.  There are definite good lines
    interspersed in between the junk.

Are the good lines complete?  Do they end with newlines?
Do they start with newlines?  At what kinds of points in the normal
and valid sequence of input does the junk get inserted?

    I can also say that the last bogus file in that directory definitely
    was written long after the last emacs crash I've had.

That doesn't surprise me, because we know that Emacs continued after
writing the junk, and wrote more good lines.

Re: huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

Richard Stallman <rms@gnu.org> wrote:

>>     I found a couple of bad files at home.  One is 1mb, the other 17mb.  I
>>     use 21.4.1 on Linux (FC6) there.  There are definite good lines
>>     interspersed in between the junk.
>> 
>> Are the good lines complete?  Do they end with newlines?
>> Do they start with newlines?  At what kinds of points in the normal
>> and valid sequence of input does the junk get inserted?

Yes.  No.  No.  Here's an example (the row of *'s is a delimiter):

**************************************** START
/home/layer/mail/inbox-spam/#1#„Ì#	+inbox-spam/1\x12I´Z\x1f	D”é*	 2D 02/05 [=?iso-8859-1?B?]  =?iso-8859-1?B?TWFyaW5lciBQcml2YXRlIFNhbGU6IFNvdXR
geté*	 1Dt02/05 ["NameBargain"  ]  Winter Special - $7.88 Transfers!<<--------------B
ì\x01+	    {%b} no msgsp/eœp\x10	mh-searcher\p\x10	Cached value of chosen search program.:Œ­\x10	mh-search-function\f­\x10	Function which executes the search program.ì¬\x10	mh-search-next-result-functiont̬\x10	Function to parse the next line of output.
Expected to return a list of three strings: name of the folder,
**************************************** END

then a lot more binary junk and then this:

**************************************** START
\x1ce/layer/mail/inbox-spam/\x01¤×#	/home/layer/mail/inbox-spam/#1#”×#	\(:-[({]\)\(\W\|\'\))\b\x14Î#	\(:-[/\]\)\(\W\|\'\)\x1e\x18	ôÍ#	\([:;]-?)\)\(\W\|\'\))\b\x0678	\x0eore--99379	\x12tf-save--99380\b\x13tf-bound--99381\x19uffer named *Summary*)\bdÍ#	\(\s-\|^\)\(_\(\(\w\|_[^_]\)+\)_\)\(\s-\|[?!.,;]\)\bDÍ#	\(\
**************************************** END

I'm reluctant to just upload the (1mb) file, because I can clearly see
it contains personal/private information.

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    then a lot more binary junk and then this:

    **************************************** START
    \x1ce/layer/mail/inbox-spam/\x01€×#	/home/layer/mail/inbox-spam/#1#”×#	\(:-[({]\)\(\W\|\'\))\b\x14Î#	\(:-[/\]\)\(\W\|\'\)\x1e\x18	ôÍ#	\([:;]-?)\)\(\W\|\'\))\b\x0678	\x0eore--99379	\x12tf-save--99380\b\x13tf-bound--99381\x19uffer named *Summary*)\bdÍ#	\(\s-\|^\)\(_\(\(\w\|_[^_]\)+\)_\)\(\s-\|[?!.,;]\)\bDÍ#	\(\

That is really strange because it looks like a file name got clobbered
near the beginning.  `/hom' apparently was replaced by stuff ending in ^\.
I can't imagine what could do that.

These file names all look strange to me.  Perhaps you are using a mail
reader that uses lots of file names in a pattern I don't recognize.
As a result, I can't tell what parts of this output is valid names.
Can you show the same output and point out which parts are part of
real meaningful file names, and what the whole file names look like?

Re: huge files in ~/.emacs.d/auto-save-list/

[Kevin Layer]

I can also say that the last bogus file in that directory definitely
was written long after the last emacs crash I've had.  The bad file
was written 4/28 and it's been months since I've had an emacs crash at
home.  (At work, I switched to emacs 22, and haven't had a crash since
that switch.  At home, I was sort of waiting to see if I had any more
crashes on 21.4, and I had not.)

Now, it very well could be related to out of memory situations.  I
remember at work noticing that on a few occasions my emacs had grown
quite large (150mb, according to top).  I even remember seeing the
(new?) message from emacs when you undo something in a buffer larger
than the threshold for storing undo info.  I'll keep an eye on this,
to see if those files appear near these types of events.

I'm also running a nightly cron job to tell me when the directory gets
big.

Re: huge files in ~/.emacs.d/auto-save-list/

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> The existing code relies on an unwind-protect to close the stream.
> Maybe something fails to run the unwind-protect.  Could you try
> running with this change, and tell us if it prevents the problem?
>
>
>
> *** fileio.c	22 Mar 2007 08:15:04 -0400	1.580
> --- fileio.c	22 May 2007 14:23:20 -0400	
> ***************
> *** 6021,6026 ****
> --- 6021,6027 ----
>   
>     /* Prevent another auto save till enough input events come in.  */
>     record_auto_save ();
> +   fclose (stream);

This will cause crashes.  First, stream may be NULL, second, using
stream after fclose is undefined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: huge files in ~/.emacs.d/auto-save-list/

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Wed, 23 May 2007 11:32:10 +0200
> Cc: bug-gnu-emacs@gnu.org
> 
> using stream after fclose is undefined.

Indeed.  So I'd suggest fflush and then fsync instead.

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    Indeed.  So I'd suggest fflush and then fsync instead.

It would not serve the purpose.  The aim of my patch was to make sure
the stream would get closed.

Re: huge files in ~/.emacs.d/auto-save-list/

[Richard Stallman]

    This will cause crashes.  First, stream may be NULL,

Indeed, it has to check that.

							 second, using
    stream after fclose is undefined.

Using the stream after it shouldn't be used any more seems to be
exactly the bug we are trying to find.

Are you talking about the second call to `fclose'?  I guess we would
have to change do_auto_save_unwind so it doesn't close the stream a
second time if it was already closed.

In any case, Layer's latest message suggests that the problem
is of a different kind, not the one this patch was intended to prevent.