ReadFrom() deadlock

[pkg]

ReadFrom() deadlock

[eikenb]

I read through this and get the basic problem but it would take a good bit of work for me to get up to speed on the client code enough to have an idea of how to address this. Given that currently my focus is almost entirely on the server side code, this may not happen. I would however have time to review a pull request. So if you have an idea of how to fix things perhaps you would consider submitting a pull request with the fix + test. I don't mean to be dismissive of your issue, rather just honest about my time and what your best chances are of getting this fixed.

Thanks.

[eikenb]

This looks very much like the hang in WriteTo fixed in PR #152. I'm going to look to see if the same fix would work here.

[nekrondev]

Thanks for your support! I am currently buried into different projects so there is little time for me right now to write test cases to probe the deadlock bug. For the tool where I used to transfer data to unreliable mobile WLAN connections the deadlock did not reappear after I fixed the sftp package like mentioned earlier.

Cheers and keep on the good work!
Nek

[eikenb]

I was reviewing the code and I think all that this would take to trigger would be 1 successfully received packet followed by 2 errors. After 1 packet inFlight would be 0 (one added, one removed) and desiredInFlight would be 2 (started at 1, incremented once). So then if it received 2 errors in a row, they would both hit the immediate channel write in dispatchRequest causing the 2nd to lock.

I'm trying to figure out a way to write a test for this right now. I have yet to find a good place to force it to start returning errors after N packets are sent. I'm thinking maybe I could change things so I could replace packet.sendPacket() with a version of it that fails after N.

[eikenb]

I replicated it.

[eikenb]

Note that this also effects client.Write() as well.