Re: [ jEdit-devel ] [ jedit-Bugs-462421 ] 3.2.2 crash, lost settings

[<dmo...@gm...>]

Hi Slava,

this bug was reported a month ago:

On Wednesday, September 19, 2001, 5:58:44 PM, no...@so... wrote:
> Bugs item #462421, was opened at 2001-09-17 19:08
> You can respond by visiting:=20
> http://sourceforge.net/tracker/=3Ffunc=3Ddetail&atid=3D100588&aid=3D46242=
1&group_id=3D588
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Steve Barrett (sjbjava)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: 3.2.2 crash, lost settings

> Initial Comment:
> I have been experiencing mysterious crshes and lockups=20
> using 3.2.2 with latest pluggins (as of 9/17/01).  My=20
> OS is Win98SE, 128 MB ram, almost nothing else running=20
> and I am using JDK 1.3.1.
> I don't know which comes first, but these two symptoms=20
> preceed the crash.  The most severe crash has been on=20
> my Win98 machine when twice I have lost my=20
> preferences.  I haven't seen this on the Win95=20
> machine, but I am also exiting and restarting the=20
> editor much more frequently, especially once I see=20
> either of the following symptoms.
> Symptom 1) The editor becomes sluggish, especially=20
> noticable during cut/paste operations, bracket=20
> matching and when deleting a line with a marker.  Also=20
> some copy/paste operations get ignored.  The the=20
> screen starts to repaint incorrectly too, if I cursor=20
> down through the file the individuals lines get=20
> repainted correctly. I hear a lot of disk thrashing=20
> although during the times I have been able to check,=20
> there was some free memory available.
> Symptom 2) Opening a file doesn't work, or the file is=20
> opened and doesn't display.  At this point if I can=20
> exit the editor normally it will restart correctly. =20
> Same thing with switching buffers.  Several times the=20
> editor has not displayed the buffer I was trying to=20
> switch to.  And twice after this the editor has frozen=20
> and (once I was eventually able to close the editor)=20
> and when I restart, I have lost all my preferences=20
> with the exception that the current session is=20
> remembered and the files that were open.  The files=20
> are opened wrong and look weird, although they appear=20
> undamaged.
> ----------------------------------------------------------------------
> Comment By: Steve Barrett (sjbjava)
> Date: 2001-09-19 08:58
> Message:
> Logged In: YES=20
> user_id=3D265244

> I haven't had a crash since I started exiting and restarting at the
> first sign it is bogging down or doing disk thrashing. If I do I will
> check the activity log. Is the log cummaltive, would it show a crash
> from several days ago=3F
> ----------------------------------------------------------------------
> Comment By: Slava Pestov (spestov)
> Date: 2001-09-19 05:41
> Message:
> Logged In: YES=20
> user_id=3D2280

> Any exceptions in the activity log=3F
> ----------------------------------------------------------------------


I still think this was caused by OutOfMemoryError. The symptoms the user
mentioned seem to support this. This would make the bug a duplicate of
#454342.

OutOfMemory is really a problem. It trashed my properties recently, too.
The reason are the following lines in jEdit.java:

2068    OutputStream out =3D new FileOutputStream(file);
2069    props.save(out,"jEdit properties");
2070    out.close();

While 2068 works correctly even with almost no available memory, 2069
fails, and the OutputStream is closed implicitely on finalization. Thus,
the resulting file becomes empty.

I know that jEdit 4.0 will consume much less memory because of the new
document model (your statistics are impressive!), but the problem will
still persist, especially because most default Java runtime
installations run only with a heap of 32 MB. The problem won't vanished,
it will just be delayed until someone edits an extremely large file.

I see that setting files are now backed up in 4.0pre1 (cool!), but this
doesn't help in the special case of OutOfMemory, because the backup file
might not be written. Or, the user might trash the valid backup, because
he runs and exits jEdit a second time.

What do you think of the following two suggestions to make property
saving at jEdit termination more reliable=3F

1) Don't try to save the properties, if free memory after GC is less
   than 1 MB. Add a log entry instead, saying "properties not saved
   because no memory available".

2) Show a warning alert if the properties are empty and a non-empty
   backup copy exists, giving the user the ability to quit jEdit
   immediately (or run in "-nosettings" mode).

3) Save the properties using the JDK 1.3 method
   Runtime.addShutdownHook(Thread). Since jEdit 4.0 now is 1.3
   compatible, it is possible. It could increase the chance, that
   properties are saved on abnormal program termination. (Although it
   won't help much on an OutOfMemoryError.)


What do you think=3F

Dirk.