bug in finalizer?
EP510777 at exchange.FRANCE.NCR.com
Tue Oct 13 02:40:15 PDT 1998
> > > Actually, it seems to work if you redirect stdout to a file. If it
> > > writes to a tty, it will *wait for input* before the finalizer
> > > proceeds every now and then. Incredible!!!
> > Doesn't sound so incredible to me...
> > I don't know what's causing it though... could you run it with
> Another (weird) datapoint. The problem occurs for me under FreeBSD,
> but if I run it under ktrace, it doesn't! Hmm.. a Heisenbug.. :-)
> It's probably some confusion at the select() system call, perhaps
> some file descriptors are getting mixed up and/or signals being
> blocked at the wrong time.
I have trackdown the SIGTTOU: I have it on MP-RAS also.
It's in jthreadedFileDescriptor(), the FIOASYNC ioctl on
STDIN, STDOUT and STDERR that cause a SIGTTOU.
As you can read in jthread_init() about BSD:
XXX this is f***ed. On BSD, we get a SIGHUP if we try to put
a proccess that has a pseudo-tty in async mode ...
but ignoring SIGHUP is done AFTER set STDIN, STDOUT and STDERR
in async mode :-(
Extract from man termio(7) Session management:
If TOSTOP is set and a member of a background process group
attempts to ioctl its controlling terminal, and that ioctl
will modify terminal parameters (e.g., TCSETA, TCSETAW,
TCSETAF, or TIOCSPGRP), its process group will be sent a
SIGTTOU signal, which will normally cause the members of
that process group to stop. If, however, the process is
ignoring or holding SIGTTOU, the ioctl will succeed.
So, ignore SIGTTOU as well SIGHUP.
In jtheadedFileDescriptor(), fcntl(fd, F_SETFD, 1) corrupts the
fildes status flags retreive by F_GETFL, the following patch correct
Hope this help,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 905 bytes
Desc: not available
Url : http://kaffe.org/pipermail/kaffe/attachments/19981013/d58a7d8c/attachment-0007.obj
More information about the kaffe