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