I've seen team hang when stderr is a file. 'top' reports that it is stuck in lockf. Fix: I haven't looked into this very deeply, but #undef'ing F_SETLKW seems to avoid the problem. This is already done for SunOS (maybe for the same reason?). How-To-Repeat: Run team with stderr set to a file. Sometimes it hangs.
Responsible Changed From-To: freebsd-ports->joerg I'm the maintainer.
As dawes@physics.usyd.edu.au wrote: > I've seen team hang when stderr is a file. 'top' reports that it is > stuck in lockf. > I haven't looked into this very deeply, but #undef'ing F_SETLKW seems to > avoid the problem. This is already done for SunOS (maybe for the same > reason?). I think team's error is it that it does both locking methods, fcntl() and flock(), if either F_SETLKW as LOCK_EX are available. Since they finally go into the same common code path in the kernel, this might cause the deadlock. I believe the code would be correctly written as: { # if (defined F_SETLKW) struct flock l; l.l_whence = 0; l.l_start = 0L; l.l_len = 0L; l.l_type = F_WRLCK; fcntl(fileno(stderr),F_SETLKW,&l); # elif (defined LOCK_EX) flock(fileno(stderr),LOCK_EX); # endif fprintf(stderr,a,b,c,d,e,f,g,h,i); # if (defined LOCK_EX) flock(fileno(stderr),LOCK_UN); # elif (defined F_SETLKW) l.l_type = F_UNLCK; fcntl(fileno(stderr),F_SETLKW,&l); # endif } Since flock() doesn't suffer from the braindeadness mentioned in the fcntl(2) man page, i'll add your suggested patch however. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
State Changed From-To: open->closed Suggested fix dropped into the `patches' directory. Thanks!