not properly interpreting EPIPE as connection reset
Bug #1047325 reported by
John A Meinel
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Fix Released
|
Critical
|
John A Meinel | ||
Bug Description
When testing the ConnectionReset code introduced in bzr-2.5b4, it appears that I missed some of the return values from send.
Specifically socket.send can raise EPIPE if the connection is completely dead. And we use socket pairs, on platforms that support them, to communicate with the ssh subprocess to not have to worry about blocking when reading more data than we *know* is in the pipe.
The patch should be reasonably small to fix. And is probably necessary for a bzr-2.5.2.
Related branches
lp:~jameinel/bzr/2.5-conn-reset-socket-pipe-1047325
- Richard Wilbur: Approve
-
Diff: 78 lines (+25/-5)3 files modifiedbzrlib/osutils.py (+5/-2)
bzrlib/smart/medium.py (+2/-2)
bzrlib/tests/test_osutils.py (+18/-1)
Revision history for this message
| John A Meinel (jameinel) wrote | #1 |
| Changed in bzr: | |
| status: | Confirmed → Fix Released |
To post a comment you must log in.
I remember now. I was trying to test disconnects with a socketpair, etc. But I wasn't able to trigger a failure on *write*. I think the issue is that the system leaves a buffer in place for a while, so a normal write would still succeed, but just be dropped, and the read side would fail.
Obviously if you have a bigger disconnect, you can get EPIPE. I just was unable to trigger it when I was working on the original patch. Clearly if you wait a long time it is possible, but we don't want a test that waits 10+s just to trigger this.