[ksh93-integration-discuss] SIGTTOU bug in b72 ksh93?

[Roland Mainz]

James Carlson wrote:
> Glenn Fowler writes:
> > On Thu, 27 Sep 2007 10:33:21 -0400 James Carlson wrote:
[snip]
> > re signal() in ksh/ast: the ast code uses signal() but it is intercepted
> > at the library layer which uses sigaction/sigvec or whatever is available
> > to coax usable signal semantics from the system implementation
> 
> OK.  As long as it's _not_ using the signal(3C) interface that's
> exported by libc, I believe that this means that CR 6586967 should not
> apply, so that shouldn't be the problem.

No, the issue doesn't apply... and at library symbol level the libast
|signal()| interface is called |_ast_signal| to make sure we don't have
something like a "namespace collision".

> The problem was a defect in the way pending signals were handled
> during a fork(2) when the caller established a self-resetting (old BSD
> style) handler using signal(3C).  In that one special case, the signal
> handler was reset _before_ the signal was delivered, causing the
> default signal to be taken.  It's the source of the otherwise
> mysterious "Alarm Clock" messages from dhcpagent.
> 
> (No idea what a "hotfix" would be here, though.  I didn't think
> Solaris had such things.)

Erm... AFAIK Sun has "hotfixes" (patch kernel at runtime) which can be
applied to a live system... but that's only done in very very rare
cases. I've abused the term "hotfix" a bit for the backport of a SIGCHLD
handler patch to our ksh93-integration tree (see
http://bugs.grommit.com/show_bug.cgi?id=311 ("Need hotfix for
memory corruption")) because it was applied very late in the
testing/putback cycle.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)