Hello Daniel,

after much debugging and sprinkling of printouts on our target platform, it
turns out that the source of the bug was 75% an application problem (mine)
and 25% (in my opinion) an libCurl issue due to the weakness of using
loosely coupled va_args to extract arguments from a variable length
argument list while setting libCurl options. The problem had to do with an
implicit 'long long' to 'long' conversion and also (I believe an Endian
related issue on the PowerPC platform that was not an issue on windows).

I use libCurl for our FTP client needs within a C++ application - linked
against the standard template C++ library. I use std::chrono::seconds
objects to set time and duration libCurl options. Under the covers
however, the std::chrono::seconds is a rather complex template type with an
internal representation of n 8 byte PPC 'long long' which differs from the
4 byte PPC 'long' that is hard coded in the options below. Due to the
loose coupling between passed in 'long long' argument and the actual
'long', the value set in CURLOPT_SERVER_RESPONSE_TIMEOUT was actually the
incorrect 4 bytes from the 8 byte 'long long' on the power PC platform. I
confirmed this by writing a snippet of code to verify how it worked on
windows and not on our 32bit PPC embedded target.

The way I set fixed the code at the application level was by ensuring that
there was an explicit cast to the same type as the va_arg 2nd parameter -
this was required as the seconds::count() method returns a long long,
without this the CURLOPT_SERVER_RESPONSE_TIMEOUT option was surprisingly
set to 0. Hope this is Helpful

                        if (flashReclTimeout) {
                            // fix for broken flash reclamation timer on
target platform
                            // caused by 'long long' to 'long' conversion
always
                            // setting a 0 in the associated timers.
                            auto timeoutSecs =
duration_cast<seconds>(flashReclTimeout.get());
                            /*auto res =
*/curl_easy_setopt(rContext.getCurlHandle(),
                                CURLOPT_TIMEOUT,
static_cast<long>(timeoutSecs.count()
+ 1));
                            /*auto res =
*/curl_easy_setopt(rContext.getCurlHandle(),
                                CURLOPT_FTP_RESPONSE_TIMEOUT,
static_cast<long>(timeoutSecs.count()));
                            ss << ", [flash reclamation timeout "
                                << timeoutSecs.count()
                                << "(s)]";
                        }

CURLcode Curl_setopt(struct SessionHandle *data, CURLoption option,
                     va_list param)
{
  char *argptr;
  CURLcode result = CURLE_OK;
  long arg;
#ifndef CURL_DISABLE_HTTP
  curl_off_t bigsize;
#endif

  switch(option) {
  case CURLOPT_DNS_CACHE_TIMEOUT:
 . . .

  case CURLOPT_SERVER_RESPONSE_TIMEOUT:
    /*
     * Option that specifies how quickly an server response must be obtained
     * before it is considered failure. For pingpong protocols.
     */
    data->set.server_response_timeout = va_arg( param , long ) * 1000;
    break;

On Mon, Dec 8, 2014 at 7:12 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> fixing bugs!
>
> If you have a few minutes, please consider browsing our bug tracker at:
>
> https://sourceforge.net/p/curl/bugs/
>
> and see if you can help us fix a bug, reproduce a bug or just add more
> findings or ideas to the existing ones.
>
> There are currently 23 open issues, most of them are unfortunately not of
> the small and easy kind.
>
> Thanks!
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> 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-12-09