>> Could I possibly get you to ktrace it or some such to find out >> what's making it die?
> One process gets a SIGPIPE. > 25570 1 unfdstress CALL write(0xb,0x11e14,0xa) > 25570 1 unfdstress RET write -1 errno 32 Broken pipe > 25570 1 unfdstress PSIG SIGPIPE SIG_DFL: code=SI_NOINFO Okay, that's a failure mode I hadn't seen myself and didn't trap. I'm not sure whether I'd rather ignore SIGPIPE and let EPIPE happen or set up a SIGPIPE handler, but I probably should do one of the two. Those systems, then, are manifesting the problem, in that the stressing processes are causing unrelated processes to see connections as broken when they shouldn't be. > Before that, everything is fighting to synchronize and most sendmsg() > and write() fail with ENOBUFS. Yup, that's the stressing processes operating as designed. They send vigorously - see busy_a() and busy_b(). Interestingly, I have since tested it on (mutant) 4.0.1 and it works just fine, even under stress. I can't as test it on 1.4T because the program is written to the broken CMSG_* API, which 1.4T predates. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
