On Fri, 2014-10-03 at 07:29 +0200, Dan Fandrich wrote:
> On Thu, Oct 02, 2014 at 02:42:58PM -0400, Dan Donahue wrote:
> > This is my first post to the libcurl mailing list. My hope is this mail
> > is "etiquettely" correct according to your mailing list rules, which I
> > read in their entirety.
>
> Bonus points!
>
Thank you for the quick reply.

> > Please review the info below and provide feedback that will help me
> > isolate the issue to either my application or libcurl.
> >
> > Info
> > ----
> > Embedded PowerPC CPU
> > libcurl 7.29.0
>
> FYI, this version is 10 versions out of date.
>
I can update to 7.38.0 and retest and report the results. However, I
would still like to root cause this issue.

> > linux kernel 3.0.34
> > libssh2 1.4.3
> > openssl 1.0.1e
> >
> > All multi sessions contained herein use sftp employing username and
> > password for authentication.
> >
> > Issue
> > -----
> > A second failed upload attempt ("Login denied (67)") during a download
> > in process causes said download to fail with: "Failed writing received
> > data to disk/application (23)". This only occurs if an upload was
> > attempted and failed prior to initiating the download.
>
> I'm confused already. Is libcurl returning error 67 or error 23? It's only
> going to return a single error code.
>
Each return (23, 67, followed by another 23) are libcurl returns for
individual easy sessions (upload, download, upload). The easy sessions
are associated with the same multi interface.
 
> > Note, the 67 error is expected because the wrong username is used.
> >
> > Download progress reports received before the second upload attempt
> > indicate download is proceeding as expected. The 23 error occurs
> > immediately after the second 67 error.
>
> So, are you describing a scenario consisting of 3 transfers, one that returns
> 67, a second one that returns 67 then a third one that returns 23?
>
Yes. Again, the sequence of return codes in this scenario are 23, 67, 23
for upload, download, upload easy sessions.

> > The 23 error occurs because the fwrite in the write function did not
> > write out all the data given (e.g. 209 != 2000). ferror for the failed
> > fwrite reports "Bad file descriptor". This occurs whether I use the
> > libcurl default write function or a registered callback.
>
> This sounds like an issue with the write callback or setting up the file handle
> used by the write callback. Unfortunately, those were the parts of the code you
> didn't send!
>
As stated in my original mail, this issue first manifested using the
default write callback in libcurl (I did not register one). During debug
I did register a callback but the problem persisted.

The set up of the file handle is in the code in my original mail. It is
fopen'd using "w+b" prior to the start of the download easy session.

I don't believe it is related to the file handle as the download
progresses nicely until the second failed upload. I also don't believe
it's associated with the write callback because the problem manifests in
both the libcurl default as well as registered callbacks.

Here is the callback I registered during debug in case you are still
interested in it:

int curlWrite(void *buffer, size_t size, size_t nmemb, void *stream)
{
     CurlClient *client = (CurlClient*)stream;

     if(client == NULL)
         return -1;

     /* open file for writing */
     if (client->fd == NULL)
     {
         client->fd = fopen(client->reqInfo.fileName, "w+b");
         if(client->fd == NULL)
             return -1;
    }

    return fwrite(buffer, size, nmemb, client->fd);
}

> >>> Dan
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-03