This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash process remains after I close rxvt in certain ways

The problem I've been having for quite a while now may or may not be
related to this but it's indeed similar.

I start XWin from a batch file that also starts a gnome-terminal.  I
always have to kill the gnome-pty-helper.exe process in order to be
able to open more terminals.  The point where it hangs varies from
just creating the second terminal to up to maybe the 7th.  I've never
seen it go beyond that before needing to kill the helper process.
This issue made me start a Sysinternals's Process Explorer window as a
pre-requisite to starting XWin and the gnome-terminals.  I now start
XWin and then look in the process explorer window for the
gnome-pty-helper process, kill it and then watch the rest of the
terminals come up.  If I look at the threads in the
gnome-pty-helper.exe process, I find two threads, one doing about 92
context switches per second with a start address at
'gnome-pty-helper.exe+0x1000' and the other one is at
cygwin1.dll!toascii+0x15d0.  This second one is a pretty common
address I see when I get cygwin runaway processes using 100% CPU but
that's a different story I think (or maybe not?)  I've killed that
thread only to see if it would help but it looks like something is
waiting for the process to finish because things only keep rolling
after I kill the process not just the thread.   Mind you, sometimes it
doesn't happen right away, that is, the second terminal starts find
even though the gnome-pty-helper.exe is still there.

The other relatead issue is that when I exit the last bash shell in
the gnome-terminals, the gnome-terminal.exe process doesn't go away
either and I have to kill that one too.  Well, actually, Process
Explorer says the the gnome-terminal.exe process is a child of a
bash.exe process as expected I guess but there are other bash shells,
those in each gnome terminal window or tab, which where started by
gnome-terminal.  They show up as siblings and not as children though.
When I kill the gnome-terminal.exe process, the bash.exe parent
process goes away by itself.

It all seems related to gnome-terminal and the related supporting
gnome packages and not to bash itself, which is basically why I
haven't posted anything about this here but this time it seems at
least somebody might tell me that indeed it's not and point in a more
hopeful direction.


Luis P Caamano
Atlanta, GA USA

On 13 Nov 2006 15:08:48 -0000,  Igor
Peshansky  wrote:

> According to Eric Lilja on 11/12/2006 12:52 PM:
> > I recently upgraded to a dual core machine which made me use the windows
> > task manager alot. That's when I noticed that if I close the rxvt window
> > by pressing 'x' in the top right corner (or doing alt-f4, I never do
> > this, just tried it now to see what happened) the rxvt process is
> > terminated and the window disappears but the "underlying" bash process
> > is still running (without a visible window), consuming ~3.5 MB of memory
> > and 0 cpu time according to the task manager.
> So far, no one has found a good way for a cygwin process killed by Alt-F4
> (or the X button) to treat that as a SIGHUP and pass that information on
> to all of its children processes.  So, by killing rxvt abruptly, you are
> indeed stranding bash as a zombie process.
> > If I exit rxvt by typing
> > exit, the bash process is terminated too.
> Actually, typing exit will exit bash, not rxvt; but when rxvt realizes
> that all of its children processes have exited, it exits as well.
> > Can I do something so the bash
> > process is always terminated properly no matter how I close the rxvt
> > window?
> Submit a patch to make cygwin processes recognize Alt-F4 as a SIGHUP that
> needs to be passed to their children?  Or possibly even a patch such that
> when a controlling pty terminal is closed, all children (such as bash)
> reading from that pty get an end-of-input (possibly a SIGPIPE) when trying
> to read from the disappearing terminal?

Actually, it's not the Cygwin processes that need that feature, but the
W11 library.  When rxvt is closed via the 'X' button or Alt-F4, Windows
sends it the WM_QUIT message, which ought to be handled properly in the
library as application exit (and thus send SIGHUP to all immediate
children).  This is done by the Cygwin console already, so it may simply
be a matter of copying/pasting some code...

> > Is there misconfiguration on my end or should I simply get in
> > the habit of always using exit to close rxvt?
> For now, that is the best course of action.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]