Re: Can close-ing a pipe trigger a SIGPIPE?
On Sat, Oct 17, 2009 at 06:04:46PM -0400, Mikhail T. wrote: Kostik Belousov написав(ла): This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Obviously, I cannot answer the question. This is something that should be read from source code or asked by authors. Source code of the application, this is probably unclear from the above sentence. You -- or someone else -- could comment like: a) Yeah, the meaning of write-ing 0 bytes changed in version such and such to conform to such and such standard. or b) No, nothing changed in that area of FreeBSD for years -- there must be something in Tcl itself. It cannot be stated in this way, since application started to issue zero-length writes. Why it started doing this, either some buggy ABI change in the base system, or buggy application noted and reacted inconsitently to the ABI addition etc cannot be even theoretized. This is why I made that formulation noting the reason should be read from the app source code. pgpKGltKKNMPh.pgp Description: PGP signature
Re: Can close-ing a pipe trigger a SIGPIPE?
On Sat, Oct 17, 2009 at 12:46:37PM -0400, Mikhail T. wrote: Hello! I'm investigating a problem caused by (what seems like a spurious) SIGPIPE. The program creates a child process using pipe, exchanges a few messages with the child (via write and read) and closes the pipe. Some times -- in about 60% of the cases -- this causes a SIGPIPE to be delivered to the parent... Now, it is quite possible for the child to have already exited by the time the parent closes its end of the pipe -- but why should that cause a SIGPIPE, unless the parent tries to write something to the widowed pipe, which it does not? From pipe(2): A pipe that has had an end closed is considered widowed. Writing on such a pipe causes the writing process to receive a SIGPIPE signal. There is no other mention of SIGPIPE in that manual page... I set SIGPIPE on ignore around the pipe-closing as a work-around, but I think, this is a bug... The thing is part of TclX' self-test (test signal-3.0) -- and it was not dying from SIGPIPE before the FreeBSD-7.x, as far as I can remember... It still seems to be fine on Linux... Have there been any changes in this area in FreeBSD? Thanks! Take ktrace of both parent and child. pgplSQFAnR1s0.pgp Description: PGP signature
Re: Can close-ing a pipe trigger a SIGPIPE?
Kostik Belousov написав(ла): Take ktrace of both parent and child. Great idea! Here is the kdump's listing for both (after ktrace -i): http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt (it is large, so be sure to use a compressing browser). Once loaded, look for substring: Error SIGPIPE signal received while closing file5. The parent process-ID is 92722. The child -- 92723. Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
Kostik Belousov написав(ла): Take ktrace of both parent and child. I can see the curious piece right here: The child exits: 92723 tclsh8.5 CALL exit(0) The parent masks SIGPIPE (as part of my workaround): 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffa9e0,0) 92722 tclsh8.5 RET sigaction 0 This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
On Sat, Oct 17, 2009 at 01:41:22PM -0400, Mikhail T. wrote: Kostik Belousov wrote: Take ktrace of both parent and child. Great idea! Here is the kdump's listing for both (after ktrace -i): http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt (it is large, so be sure to use a compressing browser). Once loaded, look for substring: Error SIGPIPE signal received while closing file5. The parent process-ID is 92722. The child -- 92723. Thanks! Yours, The interesting part of the ktrace: 92723 tclsh8.5 CALL exit(0) 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffa9e0,0) 92722 tclsh8.5 RET sigaction 0 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 It seems unwise to assume that a write(2) of 0 bytes is a noop. Even if it is, doing it is a waste of a system call. -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
Jilles Tjoelker написав(ла): It seems unwise to assume that a write(2) of 0 bytes is a noop. Even if it is, doing it is a waste of a system call. This is not my code -- it is part of the implementation of Tcl's close command. I'm trying to unravel, where this write coming from, but, meanwhile, it would be useful to find out, if FreeBSD's handling of such writes changed recently, wouldn't it? Because this self-test used to pass cleanly before, so either FreeBSD changed, or the Tcl did (not the TclX extension, which did not change in years). Thanks for your help... -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Can close-ing a pipe trigger a SIGPIPE?
On Sat, Oct 17, 2009 at 01:53:55PM -0400, Mikhail T. wrote: Kostik Belousov написав(ла): Take ktrace of both parent and child. I can see the curious piece right here: The child exits: 92723 tclsh8.5 CALL exit(0) The parent masks SIGPIPE (as part of my workaround): 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffa9e0,0) 92722 tclsh8.5 RET sigaction 0 This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Obviously, I cannot answer the question. This is something that should be read from source code or asked by authors. pgpgDQxjtN6v2.pgp Description: PGP signature
Re: Can close-ing a pipe trigger a SIGPIPE?
Kostik Belousov написав(ла): This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Obviously, I cannot answer the question. This is something that should be read from source code or asked by authors. You -- or someone else -- could comment like: a) Yeah, the meaning of write-ing 0 bytes changed in version such and such to conform to such and such standard. or b) No, nothing changed in that area of FreeBSD for years -- there must be something in Tcl itself. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
