zsh-workers
 help / color / mirror / code / Atom feed
* zsh bugs
@ 1995-08-10  3:57 Roy LIMLEY
  0 siblings, 0 replies; 2+ messages in thread
From: Roy LIMLEY @ 1995-08-10  3:57 UTC (permalink / raw)
  To: zsh-list; +Cc: sean, chris, roy, james

Dear Sir/Madam,

I was wondering if you can help me with a zsh (version 2.5.03) bug.  When we 
are running a zsh and then run another zsh on top of it.  Then if we exit
(by killing our X session) it automatically sends a SIGHUP to the first 
(parent) zsh and the second (child) zsh.  This will automatically kill the
second zsh, but not the first (we put a TRAPHUP to exit when the zsh got this 
signal).  The first zsh then become a wild process and consumes a fair bit of 
processing power.

Debugging it gave me some clue where it got stuck.  It got stuck in zle_main.c
source in line 254:

           while ( r=read(...... )
              if ( r == 0 ) {
                 if ( isset (IGNOREEOF ) )
                    continue;

My guess is that this process is trying to read a pipe from somewhere and keep
getting no message and then when it encounter the "continue" statement it
just loops back again and again,  which is what the debugger shows.

Is there already a patch to fix this problem or perhaps you can suggest a 
solution to us.  

Many thanks,

Roy Limley


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

* zsh bugs
@ 1995-07-20  5:49 Roy LIMLEY
  0 siblings, 0 replies; 2+ messages in thread
From: Roy LIMLEY @ 1995-07-20  5:49 UTC (permalink / raw)
  To: zsh-list; +Cc: unixsupport

Dear Sir/Madam,

I have just installed zsh ver 2.5.03 on our system and encountered a
perculiar bug.  Apparently the zsh process doesn't get kill when we send
a SIGHUP (15) message to it.  Some of our users log off from our system 
by killing their windows which then send the SIGHUP messages to the zsh.  But
since the zsh doesn't die from this, it becomes a wild processes and continue
to consume to CPU process.  Eventually, these wild processes accumulates and
render the system useless.

The last version that we installed (zsh-2.3.1) didn't have this problem.  Can
you suggest a solution or patches for us?

One of the solution that we found was by putting the following line in 
the .zshrc file:

    function TRAPTERM       # signal 15
    {
        fc -W $HISTFILE
        exit
    }

However, we really don't want to change everyone's .zshrc file.  Perhaps
you can offer us a better solution.


Thanks,

Roy Limley


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

end of thread, other threads:[~1995-08-10  4:10 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1995-08-10  3:57 zsh bugs Roy LIMLEY
  -- strict thread matches above, loose matches on Subject: below --
1995-07-20  5:49 Roy LIMLEY

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).