History bug still present in 3.0.3-test5

History bug still present in 3.0.3-test5

[Bart Schaefer]

I reported some while ago that zsh was failing to save history when it exits
due to a dropped connection.

This is still happening.

To see it, run

	xterm -e zsh -l

and then use the window manager to kill the xterm.  The $HISTFILE file will
be truncated to zero size.

I think the problem may be that zsh begins to save history when it gets the
EOF on standard input, and then exits without finishing the job because it
gets a SIGHUP immediately thereafter.  However, I can't be sure that this is
the problem.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts        http://www.nbn.com/people/lantern

Re: History bug still present in 3.0.3-test5

[Zoltan Hidvegi]

> I reported some while ago that zsh was failing to save history when it exits
> due to a dropped connection.
> 
> This is still happening.
> 
> To see it, run
> 
> 	xterm -e zsh -l
> 
> and then use the window manager to kill the xterm.  The $HISTFILE file will
> be truncated to zero size.

I cannot reproduce this Linux, but from the backtrace you sent earlier it
seems that the problem is that first zle notices that the input is lost and
calls zexit(), and while zexit is saving the history, zsh receives the HUP
signal.  It seems to be a kernel or xterm bug, since HUP should really come
before the input is lost.  Here is the fix.

Zoltan


*** Src/builtin.c	1997/05/06 05:12:29	3.1.2.14
--- Src/builtin.c	1997/05/11 02:59:42
***************
*** 2543,2562 ****
  void
  zexit(int val, int from_signal)
  {
      HEAPALLOC {
! 	if (isset(MONITOR)) {  /* if using job control                  */
! 	    if (!stopmsg) {
! 		scanjobs();    /* check if jobs need printing           */
! 		checkjobs();   /* check if any jobs are running/stopped */
! 		if (stopmsg) {
! 		    stopmsg = 2;
! 		    LASTALLOC_RETURN;
! 		}
! 	    } else {
! 		/* send SIGHUP to any jobs left running  */
! 		killrunjobs(from_signal);
  	    }
  	}
  	if (isset(RCS) && interact) {
  	    if (!nohistsave)
  		savehistfile(getsparam("HISTFILE"), 1, isset(APPENDHISTORY) ? 3 : 0);
--- 2543,2564 ----
  void
  zexit(int val, int from_signal)
  {
+     static int in_exit;
+ 
      HEAPALLOC {
! 	if (isset(MONITOR) && !stopmsg && !from_signal) {
! 	    scanjobs();    /* check if jobs need printing           */
! 	    checkjobs();   /* check if any jobs are running/stopped */
! 	    if (stopmsg) {
! 		stopmsg = 2;
! 		LASTALLOC_RETURN;
  	    }
  	}
+ 	if (in_exit++ && from_signal)
+ 	    LASTALLOC_RETURN;
+ 	if (isset(MONITOR))
+ 	    /* send SIGHUP to any jobs left running  */
+ 	    killrunjobs(from_signal);
  	if (isset(RCS) && interact) {
  	    if (!nohistsave)
  		savehistfile(getsparam("HISTFILE"), 1, isset(APPENDHISTORY) ? 3 : 0);

Re: History bug still present in 3.0.3-test5

[Bart Schaefer]

On May 10, 11:14pm, Zoltan Hidvegi wrote:
} Subject: Re: History bug still present in 3.0.3-test5
}
} > 	xterm -e zsh -l
} > 
} > and then use the window manager to kill the xterm.  The $HISTFILE file will
} > be truncated to zero size.
} 
} I cannot reproduce this Linux

I'm running my own compile of 2.0.28, dropped into a RedHat 4.0 installation,
on a 100MHz Pentium with SCSI drives.  Just in case you think that matters.

} but from the backtrace you sent earlier it
} seems that the problem is that first zle notices that the input is lost and
} calls zexit(), and while zexit is saving the history, zsh receives the HUP
} signal.  It seems to be a kernel or xterm bug, since HUP should really come
} before the input is lost.  Here is the fix.

I applied this patch and tried the xterm -e test above, and once again got
a truncated-to-zero history file.  So whatever is going on isn't related
to this patch.  And it happens with `zsh -f -l' too, so it's not some odd
thing I'm doing.

Here's a more complete stack trace.  3.0.3-test5 with the patch from your
message applied.  I only see zexit in there once, called from handler(),
so I don't think zsh has seen the EOF yet.

(gdb) where
#0  0x8061120 in savehistfile (s=0x80efee0 "/home/schaefer/.zhistory", err=1, 
    app=0) at ../../zsh-3.0.3-test5/Src/hist.c:1433
#1  0x8050a93 in zexit (val=1, from_signal=1)
    at ../../zsh-3.0.3-test5/Src/builtin.c:4640
#2  0x8070093 in handler (sig=1) at ../../zsh-3.0.3-test5/Src/signals.c:470
#3  0xbffff658 in ?? ()
#4  0x807dc34 in getkey (keytmout=0)
    at ../../zsh-3.0.3-test5/Src/zle_main.c:284
#5  0x807e505 in getkeycmd () at ../../zsh-3.0.3-test5/Src/zle_main.c:520
#6  0x807e153 in zleread (lp=0x80e67d0 "%m[%h] ", rp=0x80e67e0 "%n")
    at ../../zsh-3.0.3-test5/Src/zle_main.c:430
#7  0x8062ed7 in inputline () at ../../zsh-3.0.3-test5/Src/input.c:228
#8  0x8062df5 in ingetc () at ../../zsh-3.0.3-test5/Src/input.c:184
#9  0x805ec79 in hgetc () at ../../zsh-3.0.3-test5/Src/hist.c:118
#10 0x8065331 in gettok () at ../../zsh-3.0.3-test5/Src/lex.c:361
#11 0x8064ea9 in yylex () at ../../zsh-3.0.3-test5/Src/lex.c:176
#12 0x806d99c in parse_event () at ../../zsh-3.0.3-test5/Src/parse.c:59
#13 0x80616ea in loop (toplevel=1) at ../../zsh-3.0.3-test5/Src/init.c:117
#14 0x8061607 in main (argc=2, argv=0xbffff954)
    at ../../zsh-3.0.3-test5/Src/init.c:77
#15 0x80480eb in _start ()
(gdb) p t
$1 = 0x0
(gdb) p ev
5

[There were only 4 events in the history.  Starting from an empty history,
I typed exactly 4 commands before killing the xterm.  Looks like it's
trying to save an event that hasn't happened yet?]


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts        http://www.nbn.com/people/lantern

Re: History bug still present in 3.0.3-test5

[Zoltan Hidvegi]

> I applied this patch and tried the xterm -e test above, and once again got
> a truncated-to-zero history file.  So whatever is going on isn't related
> to this patch.  And it happens with `zsh -f -l' too, so it's not some odd
> thing I'm doing.
> 
> Here's a more complete stack trace.  3.0.3-test5 with the patch from your
> message applied.  I only see zexit in there once, called from handler(),
> so I don't think zsh has seen the EOF yet.

Yes, this trace is different from the trace you sent earlier.  I was now
able to reproduce the bug.  The bug does not happen when HISTSIZE ==
SAVEHIST and the history file is full (i.e. has as least SAVEHIST lines),
that's why I did not see the bug before.  Here is an other fix.

Zoltan


*** Src/hist.c	1997/05/07 08:25:04	3.1.2.3
--- Src/hist.c	1997/05/11 06:08:08
***************
*** 1484,1490 ****
      else
  	out = fdopen(open(unmeta(s), O_CREAT | O_WRONLY | O_TRUNC, 0600), "w");
      if (out) {
! 	for (; ev <= curhist; ev++) {
  	    ent = gethistent(ev);
  	    if (app & 2) {
  		if (ent->flags & HIST_OLD)
--- 1484,1490 ----
      else
  	out = fdopen(open(unmeta(s), O_CREAT | O_WRONLY | O_TRUNC, 0600), "w");
      if (out) {
! 	for (; ev <= curhist - !!histactive; ev++) {
  	    ent = gethistent(ev);
  	    if (app & 2) {
  		if (ent->flags & HIST_OLD)