Re: zsh 3.1.9 problem debugging linux threads

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

Mixing up the order of things a bit:

On Oct 12,  7:07pm, Gray Watson wrote:
}
} Question: What file/line of the zsh code actually writes out this
} line?

It's from printjob() in jobs.c, where sigmsg(WSTOPSIG(pn->status)) is
referenced (line 712 in my copy).

} 	zsh: 2161 suspended (tty output)  gdb intel_redhat_6_2/cmd

If it says "(tty output)", then SIGTTOU is the signal that the child
received.

On Oct 12,  7:07pm, Gray Watson wrote:
}
} Scratch that.  It is SIGCHLD.  Looks like the pthread clone delivers a
} SIGCHLD and zsh thinks that gdb is being suspended for some reason.

The SIGCHLD is delivered to zsh to alert it that the status of the child
has changed.  This has nothing to do with the signal that the child has
received, except that the child stopped running because of it.

On Oct 12,  4:43pm, Gray Watson wrote:
}
} Sorry if this is a known problem.

No, we've never heard of this particular thing before, though there have
been some previous reports of "stty tostop" problems.

Have you tried using "stty -tostop" before starting GDB?

} I cannot debug threaded programs under Linux RH6.2 with gdb:
} 
} 	> gdb a.out
} 	GNU gdb 19991004
} 	...
} 	(gdb) run
} 	Starting program: 	
} 	zsh: 30840 suspended (tty output)  gdb intel_redhat_6_2/cmd

As you probably know, SIGTTOU is sent to a process that is not the "tty
process group leader" when it attempts to produce output to the tty.
When the MONITOR option is set, zsh resets SIGTTOU to default handling
in each child that it forks, *before* exec()ing the external program.

The "default handling" of SIGTTOU is for the process to stop.  However,
I don't know why GDB is not be the process group leader -- certainly zsh
attempts to make it so.

You aren't running gdb from some kind of zsh function wrapper, are you?

} I'm guessing that zsh is trapping the signals that are generated by the
} the pthreads library calls under linux.

No, once zsh has started gdb, gdb should be entirely in control of its
own set of signal traps.  The threaded process started from within gdb
is a child of gdb, not of the shell, so zsh can't get any signals that
it generates (well, except for an explicit kill() of zsh's PID).

This is definitely a tty-process-group-handling problem of some kind.  We
have previously encountered programs that assumed incorrectly that they
either were or were not the tty process group leader (mutt was one very
serious culprit, I seem to recall).  I wouldn't have expected gdb to have
this sort of difficulty, though.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net