From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13460 invoked from network); 13 Oct 2000 03:08:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Oct 2000 03:08:21 -0000 Received: (qmail 12157 invoked by alias); 13 Oct 2000 03:07:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12994 Received: (qmail 12150 invoked from network); 13 Oct 2000 03:07:41 -0000 From: "Bart Schaefer" Message-Id: <1001013030729.ZM4967@candle.brasslantern.com> Date: Fri, 13 Oct 2000 03:07:29 +0000 In-Reply-To: <39E62288.BE76D77F@lycos-inc.com> Comments: In reply to Gray Watson "zsh 3.1.9 problem debugging linux threads" (Oct 12, 4:43pm) References: <39E62288.BE76D77F@lycos-inc.com> In-Reply-To: Comments: In reply to Gray Watson "Re: zsh 3.1.9 problem debugging linux threads" (Oct 12, 5:34pm) In-Reply-To: Comments: In reply to Gray Watson "Re: Re: zsh 3.1.9 problem debugging linux threads" (Oct 12, 7:07pm) X-Mailer: Z-Mail (5.0.0 30July97) To: Gray Watson , zsh-workers@sunsite.auc.dk, gray@256.com Subject: Re: zsh 3.1.9 problem debugging linux threads MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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