Subject: Re: libssh2_sftp_write fails with return code -1

Re: libssh2_sftp_write fails with return code -1

From: Daniel Stenberg <>
Date: Mon, 1 Nov 2010 09:58:59 +0100 (CET)

On Sun, 31 Oct 2010, Mark Riordan wrote:

> Alas, when debug is on, the uploads succeed. I tried several times. I have
> a 649 MB trace log, but I won't upload it, since it doesn't show any
> failures.

Argh, so it's one of THOSE. Yes, the debug output changes a lot of timing and
characteristics so it's not that unusual.

> With debug off, transfers of my large test file fail, more or less as
> before. Though with the version of libssh2 compiled with LIBSSH2DEBUG
> defined, sometimes 100 or more libssh2_sftp_write calls will succeed before
> one returns -1.

I've worked on getting rid of all the -1 return codes since it is too generic
error (that previously was used pretty much all over and didn't really help
much). I found some new cases that would cause -1 to get returned just now
though, and I've pushed a change that hopefully will make you get a different
error code (and error message) that can be useful to better track this down.
Please get these changes and re-run.

We need to figure out exactly which code that (thinks it) detects a problem
and returns error.

> The failures do not always occur at the same point, even though I'm
> using the same test file each time.

Which makes it sound even more like timing and network traffic related.

How big file do you send? How's the round-trip delay between your client and
the server (roughly)?

What server software are you using?

> I've noticed that the average number of bytes sent per call of
> libssh2_sftp_write is smaller with the LIBSSH2DEBUG version,
> even if debug is turned off.

Hm, I can only assume that is because a few things more are done so it runs a
bit slower.

> I put the source to my program, plus Windows executable, at:

BTW, for some further testing you could try to extend your upload buffer size
from 32500 to something like 100K or so. Current git doesn't use 32500
internally at all, and should even run better with larger buffers.

Received on 2010-11-01