tmux in cygwin -> defunct processes

[Mark Volkmann]

I have the latest version of tmux from cygwin. Previous versions worked
fine, but now it frequently hangs. When it does this, I open a new terminal
window, run "ps -ef | tmux" and see a tmux process that is marked as
"<defunct>". Killing the process and starting a new tmux session or
reattaching to the existing one doesn't help. It just becomes default again
within a couple of minutes. Is anyone else seeing this in cygwin?

[J Raynor]

I’m not seeing a hang, but I do see a defunct process. It appears to
be due to a race condition.

Tmux startup is a little slow on cygwin, which I think is what’s
triggering the race condition. It looks like tmux ends up setting
client_attached=1 before the child process in daemon() exits. As a
result, when the tmux client gets SIGCHLD, it won’t call waitpid() in
client_signal(), so the defunct process remains. This only happens
the first time tmux is started. If you detach and then reattach, the
defunct process will go away.

Nicholas, is there any harm in always processing SIGCHLD in the
client? That’s one way around the race condition. I’ve attached a
patch for that.


Mark, if you're running the 32 bit version of cygwin, when the tmux
server hangs, try this:

dumper tmux PID (where PID is the process ID of the tmux server)

This will create a file called tmux.core. Then do this:

gdb `which tmux` tmux.core

This will start gdb. At the prompt enter 'bt' to get a backtrace.
You can post that and we'll see if that gives a clue about what's
happening.

If you're running the 64 bit version of cygwin, you might be out of
luck. Gdb doesn't seem to work.

[Nicholas Marriott]

Yes IIRC fork on Cygwin is notoriously crappy because Windows doesn't
really work that way (doesn't it have to pass the address space through
a pipe?). This seems harmless, applied it - thanks

I???m not seeing a hang, but I do see a defunct process. It appears to
be due to a race condition.
Tmux startup is a little slow on cygwin, which I think is what???s
triggering the race condition. It looks like tmux ends up setting
client_attached=1 before the child process in daemon() exits. As a
result, when the tmux client gets SIGCHLD, it won???t call waitpid() in
client_signal(), so the defunct process remains. This only happens
the first time tmux is started. If you detach and then reattach, the
defunct process will go away.
Nicholas, is there any harm in always processing SIGCHLD in the
client? That???s one way around the race condition. I???ve attached a
patch for that.
Mark, if you're running the 32 bit version of cygwin, when the tmux
dumper tmux PID (where PID is the process ID of the tmux server)
gdb `which tmux` tmux.core
This will start gdb. At the prompt enter 'bt' to get a backtrace.
You can post that and we'll see if that gives a clue about what's
happening.
If you're running the 64 bit version of cygwin, you might be out of
luck. Gdb doesn't seem to work.
diff --git a/client.c b/client.c
index 6ab53e4..9b376e4 100644
--- a/client.c
+++ b/client.c
@@ -437,15 +437,11 @@ client_signal(int sig, unused short events, unused void *data)
struct sigaction sigact;
int status;
- if (!client_attached) {
- switch (sig) {
+ if (sig == SIGCHLD) {
waitpid(WAIT_ANY, &status, WNOHANG);
- break;
+ } else if (!client_attached) {
+ if (sig == SIGTERM)
event_loopexit(NULL);
- break;
- }
} else {
switch (sig) {
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users