Wegener pointed out that CURLINFO_APPCONNECT_TIME didn't work with the multi
  interface and provided a patch that fixed the problem!

Previous workaround proved useful, and finally did not trigger any warning!

as things don't work right here!

Previous workaround proved useful, but triggered the following warning:

warning #556: a value of type "volatile Curl_addrinfo *" cannot be assigned to an entity of type "Curl_addrinfo *"

  Koenig pointed out that the man page didn't tell that the *_proxy
  environment variables can be specified lower case or UPPER CASE and the
  lower case takes precedence,

The #pragma optimize("", off) attempt did not fix the problem and SIGSEGV's in Curl_freeaddrinfo() were back.

Previous 'volatile' variables workaround proved useful, but it triggered the following warning:

warning #167: argument of type "volatile Curl_addrinfo *" is incompatible with parameter of type "void *"

setup_once.h.  Inclusion of each header file is based on the definition of
NEED_MALLOC_H and NEED_MEMORY_H respectively.

  how it occurs (http://curl.haxx.se/mail/lib-2009-04/0289.html). The
  conclusion was that if an error is detected and Curl_done() is called for
  the connection, ftp_done() could at times return another error code that
  then would take precedence and that new code confused existing logic that
  works for the first error code (CURLE_SEND_ERROR) only.

  OBJECTPOINT options. Now we've introduced a new function - my_setopt_str -
  within the app for setting plain string options to avoid the risk of this
  mistake happening.

  for any further requests or transfers. The work-around is then to close that
  handle with curl_easy_cleanup() and create a new. Some more details:
  http://curl.haxx.se/mail/lib-2009-04/0300.html

"pointer to a char pointer".

  proxy. libcurl would then wrongly close the connection after each
  request. In his case it had the weird side-effect that it killed NTLM auth
  for the proxy causing an inifinite loop!

  I added test case 1098 to verify this fix. The test case does however not
  properly verify that the transfers are done persistently - as I couldn't
  think of a clever way to achieve it right now - but you need to read the
  stderr output after a test run to see that it truly did the right thing.