Re: Problems with trap handling?

Re: Problems with trap handling?

[Sven Wischnowsky]

Bart Schaefer wrote:

> This may be related to my "infinite loop" report:
> 
> function tst() {
>   trap return INT 
>   read -q xx'?Type ^C here: '
>   echo You should not see this.
> }
> 
> Execute in 3.1.6-dev-16 and type ^C.  Note that you don't leave the "read"
> prompt.  Type any plain character; now "read" returns, and the function
> aborts as if interrupted.

Completely different problem. No patch yet -- I'm not sure:

In this incanartion read ends up in read1char() which explicitly does
*not* stop if the read returns with errno==EINTR. So I guess someone
had a reason for doing this way.

We could either test retflag/breaks/contflag there or give it a flag
that says to stop in case of EINTR and which would be set by bin_read
(via getquery()).

Of course, there are also be other solutions...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Problems with trap handling?

[Peter Stephenson]

Sven Wischnowsky wrote:
> Bart Schaefer wrote:
> > function tst() {
> >   trap return INT 
> >   read -q xx'?Type ^C here: '
> >   echo You should not see this.
> > }
> > 
> > Execute in 3.1.6-dev-16 and type ^C.  Note that you don't leave the "read"
> > prompt.  Type any plain character; now "read" returns, and the function
> > aborts as if interrupted.
> 
> In this incanartion read ends up in read1char() which explicitly does
> *not* stop if the read returns with errno==EINTR. So I guess someone
> had a reason for doing this way.
> 
> We could either test retflag/breaks/contflag there or give it a flag
> that says to stop in case of EINTR and which would be set by bin_read
> (via getquery()).

I think the answer is it should be testing more flags at this point:
whatever's making the function return (i.e. retflag) should make the read
return, too. It's certainly correct that EINTR shouldn't make it return ---
the problem was that the query aborted if, say, a background job exited,
and as far as I can see the same issue applies to any call to read1char().
It's quite possible the same issue comes up at umpteen other places in the
code, alas.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

Re: Problems with trap handling?

[Bart Schaefer]

On Feb 2,  4:30pm, Sven Wischnowsky wrote:
} Subject: Re: Problems with trap handling?
}
} James Kirkpatrick wrote:
} 
} > I've slowly (too slowly!) been working with Bart Schaefer since around
} > November to determine the nature of a loop that occurs if you turn on
} > history files.  It appears that (for example) a disconnect (hangup) causes
} > zsh to loop in a manner where it consumes all available memory, severely
} > impacting other users, until it presumably finally aborts.  Putting a
} >   TRAPHUP () { exit 1 }
} > works around the problem but I need to try a patch Bart sent me as well.
} 
} Hm, I think I vaguely remember the problem you described (unless you
} never posted it to the list, in which case I vaguely remember
} something completely different). Dunno if it has anything to do with
} the bugs I'm trying to fight... (but I don't think so, I would need to 
} know where it hangs).

It appears to be repeatedly calling a signal handler.  I'm not able to
reproduce the bug on my Linux box.

Following is the patch to which James referred.  It simply makes sure that
zsh doesn't HUP itself when exiting.  It seems like a reasonable enough
precaution.

Index: Src/signals.c
===================================================================
@@ -540,7 +540,8 @@
         if ((from_signal || i != thisjob) && (jobtab[i].stat & STAT_LOCKED) &&
             !(jobtab[i].stat & STAT_NOPRINT) &&
             !(jobtab[i].stat & STAT_STOPPED)) {
-            if (killpg(jobtab[i].gleader, SIGHUP) != -1)
+            if (jobtab[i].gleader != getpid() &&
+		killpg(jobtab[i].gleader, SIGHUP) != -1)
                 killed++;
         }
     if (killed)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Problems with trap handling?

[Sven Wischnowsky]

James Kirkpatrick wrote:

> On Wed, 2 Feb 2000, Sven Wischnowsky wrote:
> 
> > ... Anybody know of any other
> > almost-endless loops in the code?
> 
> I've slowly (too slowly!) been working with Bart Schaefer since around
> November to determine the nature of a loop that occurs if you turn on
> history files.  It appears that (for example) a disconnect (hangup) causes
> zsh to loop in a manner where it consumes all available memory, severely
> impacting other users, until it presumably finally aborts.  Putting a
>   TRAPHUP () { exit 1 }
> works around the problem but I need to try a patch Bart sent me as well.
> 
> Is this the sort of almost-endless loop you wanted to know about?

Actually I meant loops in the C-code that are exited only under
certain conditions but not because some trap handler calls break,
return or continue.

Hm, I think I vaguely remember the problem you described (unless you
never posted it to the list, in which case I vaguely remember
something completely different). Dunno if it has anything to do with
the bugs I'm trying to fight... (but I don't think so, I would need to 
know where it hangs).


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Problems with trap handling?

[James Kirkpatrick]

On Wed, 2 Feb 2000, Sven Wischnowsky wrote:

> ... Anybody know of any other
> almost-endless loops in the code?

I've slowly (too slowly!) been working with Bart Schaefer since around
November to determine the nature of a loop that occurs if you turn on
history files.  It appears that (for example) a disconnect (hangup) causes
zsh to loop in a manner where it consumes all available memory, severely
impacting other users, until it presumably finally aborts.  Putting a
  TRAPHUP () { exit 1 }
works around the problem but I need to try a patch Bart sent me as well.

Is this the sort of almost-endless loop you wanted to know about?

Jim

Re: Problems with trap handling?

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> > 
> > We could either test retflag/breaks/contflag there or give it a flag
> > that says to stop in case of EINTR and which would be set by bin_read
> > (via getquery()).
> 
> I think the answer is it should be testing more flags at this point:
> whatever's making the function return (i.e. retflag) should make the read
> return, too. It's certainly correct that EINTR shouldn't make it return ---
> the problem was that the query aborted if, say, a background job exited,
> and as far as I can see the same issue applies to any call to read1char().
> It's quite possible the same issue comes up at umpteen other places in the
> code, alas.

Exactly what I'm fearing, too. Anybody know of any other
almost-endless loops in the code?

Bye
 Sven

diff -ru ../z.old/Src/utils.c Src/utils.c
--- ../z.old/Src/utils.c	Tue Feb  1 14:47:39 2000
+++ Src/utils.c	Wed Feb  2 09:30:29 2000
@@ -1300,7 +1300,7 @@
     char c;
 
     while (read(SHTTY, &c, 1) != 1) {
-	if (errno != EINTR || errflag)
+	if (errno != EINTR || errflag || retflag || breaks || contflag)
 	    return -1;
     }
     return STOUC(c);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Problems with trap handling?

[Bart Schaefer]

This may be related to my "infinite loop" report:

function tst() {
  trap return INT 
  read -q xx'?Type ^C here: '
  echo You should not see this.
}

Execute in 3.1.6-dev-16 and type ^C.  Note that you don't leave the "read"
prompt.  Type any plain character; now "read" returns, and the function
aborts as if interrupted.

This and the previous report are on Linux, RH5.2.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com