| Ticket UUID: | 1696642 | |||
| Title: | sigpipes in test suite | |||
| Type: | Bug | Version: | obsolete: 8.5a6 | |
| Submitter: | msofer | Created on: | 2007-04-08 23:32:21 | |
| Subsystem: | 25. Channel System | Assigned To: | andreas_kupries | |
| Priority: | 2 | Severity: | ||
| Status: | Open | Last Modified: | 2007-04-11 16:59:28 | |
| Resolution: | None | Closed By: | ||
| Closed on: | ||||
| Description: |
With today's head on linux, running a --disable-shared --enable-symbols=all test under gdb (make gdb-test), there is a sigpipe in http.test. Partial backtrace attached. (Bug found by dgp) | |||
| User Comments: |
dgp added on 2007-04-10 20:25:54:
Logged In: YES user_id=80530 Originator: NO aha! an effective workaround. prio lower still. das added on 2007-04-10 19:40:20: Logged In: YES user_id=90580 Originator: NO For exactly this reason, I have the following in my .gdbinit: handle SIGPIPE nostop noprint I routinely run the testsuite in gdb from Xcode, and this allows it to complete without interruptions... dgp added on 2007-04-10 10:08:13: Logged In: YES user_id=80530 Originator: NO better example of the issue is test io-29.27. Comments there indicate that running such tests in a debugger will have this problem. Perhaps some constraints would be useful to allow the `make gdb-test` target to run to completion, but seems less likely there's any real bug behind this. dropping prio. andreas_kupries added on 2007-04-10 03:33:20: Logged In: YES
user_id=75003
Originator: NO
Given that there is a backtrace does this mean that the core crashed ?
I thought that a SIGPIPE simply causes a Tcl error to be thrown, something which can be caught ? Although, I have seen that only for actual pipes i.e. 'tclsh ... | ...' and the sigpipe happens when the consumer exists before the tclsh, pulling the rug out under tclsh.
What does SIGPIPE means for a socket connection ? ... Ok, google (sigpipe, socket) delivers <<http://docs.hp.com/en/32650-90372/ch02s14.html>>, quoting:
A SIGPIPE is generated when a send operation is attempted on a broken socket.
One way of breaking a socket is to do a shutdown(,2) on a socket.
That is the same semantics as for actual pipes, so I guess that we should behave in the same wat, throw a Tcl error.
So we simply might have to catch the sigpipe and throw as tcl errors, as we do for regular pipes. ... The relevant files for that seem to be "tclUnixInit.c" and "tclUnixPipe.c", just look for 'SIGPIPE'. ... Hm. The code in UnixInit does a global SIG_IGN for this signal, to ignore it, so this should apply to sockets as well!
Which of the test cases in http.test is actually breaking ?
Could it be that gdb overrides our handling of sigpipe ?
In that case the 'crash' might simply an artifact of execution under gdb and not an actual bug.
dgp added on 2007-04-09 21:36:18: Logged In: YES user_id=80530 Originator: NO and older releases than that don't have a gdb-test target, so further testing is non-trivial. Apparently there's some long-term issue lurking here. dgp added on 2007-04-09 21:18:50: Logged In: YES user_id=80530 Originator: NO ditto 8.5a4... ditto 8.5a2... dgp added on 2007-04-09 21:05:15: Logged In: YES user_id=80530 Originator: NO same issue is in the 8.5a5 release. msofer added on 2007-04-09 06:32:22: File Added - 224193: backtrace.txt | |||
Attachments:
- backtrace.txt [download] added by msofer on 2007-04-09 06:32:21. [details]