zsh 3.1.9 problem debugging linux threads

zsh 3.1.9 problem debugging linux threads

[Gray Watson]

Sorry if this is a known problem.  I didn't see any mention in the FAQ
or the known bugs list.

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
        Exit 22
	> fg
        [1]  - continued  gdb intel_redhat_6_2/cmd
        [New Thread 30841 (initial thread)]
        [New Thread 30846]

        Program received signal SIGTTOU, Stopped (tty output).
        0x4011ab14 in __libc_write () from /lib/libc.so.6

Gdb suspends itself without any keystrokes from mine.  If I log in under
another shell, I have no problems.  Wierd huh?  Thought sure I had a
kernel, egcs, libc, gdb, etc. problem but no.  Definately a problem with
zsh 3.1.6 + 3.1.9.

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

Please send me mail with ideas on how to fix this.  Thanks.
-- 
Gray Watson <gwatson@lycos-inc.com>

Re: zsh 3.1.9 problem debugging linux threads

[Gray Watson]

> I cannot debug threaded programs under Linux RH6.2 with gdb:
...

This is a problem only when the monitor option is enabled which
controls the signal SIGTTOU.  I'm not sure why but it looks like this
signal is generated from inside of a linux threaded application.
---
gray.reply@256.com

Re: Re: zsh 3.1.9 problem debugging linux threads

[Gray Watson]

> > I cannot debug threaded programs under Linux RH6.2 with gdb:
> ...
> 
> This is a problem only when the monitor option is enabled which
> controls the signal SIGTTOU.  I'm not sure why but it looks like this
> signal is generated from inside of a linux threaded application.

Scratch that.  It is SIGCHLD.  Looks like the pthread clone delivers a
SIGCHLD and zsh thinks that gdb is being suspended for some reason.

Question: What file/line of the zsh code actually writes out this
line?  It seems to not be in any of the signal handlers nor
waitpid/job/jobs functions.  This would be helpful in finding out how
the child signal is being processed.

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

Thanks much,
---
gray.reply@256.com

Re: zsh 3.1.9 problem debugging linux threads

[Bart Schaefer]

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   

Re: zsh 3.1.9 problem debugging linux threads

[Bart Schaefer]

For the record:

On Oct 12,  4:43pm, Gray Watson wrote:
}
} I cannot debug threaded programs under Linux RH6.2 with gdb:
} 
}         Program received signal SIGTTOU, Stopped (tty output).
}         0x4011ab14 in __libc_write () from /lib/libc.so.6
} 
} Gdb suspends itself without any keystrokes from mine.  If I log in under
} another shell, I have no problems.  Wierd huh?

I've been trading some private mail with Gray, and this problem turns out
to be a gdb issue rather than a zsh issue.  The reason that zsh was the
only shell exhibiting the behavior had to do with "stty tostop" combined
with some confusion over "ttyctl -f".  Gdb exhibits the same behavior in
bash if "stty tostop" is in effect.

I've suggested that Gray report this to the gdb bug list.

-- 
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