Bug 3215 - signal-misdelivery in X?
Summary: signal-misdelivery in X?
Keywords:
Status: CLOSED DUPLICATE of bug 2767
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-02 17:31 UTC by aaron
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 1999-06-02 18:22:12 UTC
Embargoed:


Attachments (Terms of Use)

Description aaron 1999-06-02 17:31:24 UTC
I'm not sure whether or not the problem is a kernel signal
delivery one, or whether it's just the new version of Xfree
programs being flaky, but I'm finding this extremely
annoying.

If I kill an xterm with a SIGTERM, it goes comatose instead
of killing its child shell and going away.

select(8, [6 7], [], NULL, NULL)        = ? ERESTARTNOHAND
(To be restarted)
--- SIGTERM (Terminated) ---
fork()                                  = 1350
wait4(1350, NULL, 0, NULL)              = 1350
--- SIGCHLD (Child exited) ---
wait4(-1,

at which point it just sits, which of course during a logout
leads to a bunch of xterms and their child shells sitting
around in the process table, eating ptys and memory for not
reason at all.  The same fate awaits any processes run from
a user's .xsession.

if a SIGHUP is sent to the child shell, then the xterm
exits.

Repeating the same experiment on a NetBSD box leads to the
expected results, with no orphaned xterms in the process
table after a logout.

I'm running a 400Mhz K6-2, stepping 12, with kernel 2.2.5 as
shipped with RH6.0  I have tried kernels 2.2.4, 2.2.9, and
2.3.4 compiled with gcc 2.7.2.3 and egcs without any
success.

This signal misdelivery also shows up on my AMD 5x86-133 at
home, also running RH6.0 with distributed 2.2.5 kernel.

Comment 1 Jeff Johnson 1999-06-02 18:22:59 UTC
*** This bug has been marked as a duplicate of 2767 ***


Note You need to log in before you can comment on or make changes to this bug.