[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-bugs
Subject:    Re: [osol-bugs] [ksh93-integration-discuss] SIGTTOU bug in b72
From:       James Carlson <james.d.carlson () sun ! com>
Date:       2007-09-27 15:57:27
Message-ID: 18171.53991.208886.276189 () gargle ! gargle ! HOWL
[Download RAW message or body]

Glenn Fowler writes:
> On Thu, 27 Sep 2007 10:33:21 -0400 James Carlson wrote:
> > William Pursell writes:
> > > On 9/26/07, Roland Mainz <roland.mainz@nrubsig.org> wrote:
> > > > AFAIK it was http://bugs.grommit.com/show_bug.cgi?id=206 and it went
> > > > away on our test machines after applying the hotfix for
> > > > http://bugs.grommit.com/show_bug.cgi?id=311 ... the question is now
> > > > where this xx@@@!!! is hiding now... ;-(
> > > 
> > > Maybe that's CR 6598201. A previous fix in libc (6586967) broke the
> > > signal(3C) interface
> 
> > Unless you're a canary-in-the-coal-mine sort of application, like this
> > odd corner case in dhcpagent, I'd hope that you're not using the old
> > BSD-style signal(3C) interfaces in any modern software.  sigaction(2)
> > works _far_ better.
> 
> the sea of cr numbers and hotfixes has me at a loss
> is ksh implicated on a standard bleeding edge system or not?
> 
> 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.

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

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
opensolaris-bugs mailing list
opensolaris-bugs@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]