Skip to content
  1. Mar 16, 2015
    • Daniel Stenberg's avatar
      free: instead of Curl_safefree() · 0f4a03cb
      Daniel Stenberg authored
      Since we just started make use of free(NULL) in order to simplify code,
      this change takes it a step further and:
      
      - converts lots of Curl_safefree() calls to good old free()
      - makes Curl_safefree() not check the pointer before free()
      
      The (new) rule of thumb is: if you really want a function call that
      frees a pointer and then assigns it to NULL, then use Curl_safefree().
      But we will prefer just using free() from now on.
      0f4a03cb
    • Markus Elfring's avatar
      Bug #149: Deletion of unnecessary checks before a few calls of cURL functions · 9e661601
      Markus Elfring authored
      
      
      The following functions return immediately if a null pointer was passed.
      * Curl_cookie_cleanup
      * curl_formfree
      
      It is therefore not needed that a function caller repeats a corresponding check.
      
      This issue was fixed by using the software Coccinelle 1.0.0-rc24.
      
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      9e661601
    • Markus Elfring's avatar
      Bug #149: Deletion of unnecessary checks before calls of the function "free" · 29c655c0
      Markus Elfring authored
      The function "free" is documented in the way that no action shall occur for
      a passed null pointer. It is therefore not needed that a function caller
      repeats a corresponding check.
      http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first
      
      
      
      This issue was fixed by using the software Coccinelle 1.0.0-rc24.
      
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      29c655c0
    • Jay Satiro's avatar
      connect: Fix happy eyeballs logic for IPv4-only builds · 059b3a57
      Jay Satiro authored
      Bug: https://github.com/bagder/curl/pull/168
      
      (trynextip)
      - Don't try the "other" protocol family unless IPv6 is available. In an
      IPv4-only build the other family can only be IPv6 which is unavailable.
      
      This change essentially stops IPv4-only builds from attempting the
      "happy eyeballs" secondary parallel connection that is supposed to be
      used by the "other" address family.
      
      Prior to this change in IPv4-only builds that secondary parallel
      connection attempt could be erroneously used by the same family (IPv4)
      which caused a bug where every address after the first for a host could
      be tried twice, often in parallel. This change fixes that bug. An
      example of the bug is shown below.
      
      Assume MTEST resolves to 3 addresses 127.0.0.2, 127.0.0.3 and 127.0.0.4:
      
      * STATE: INIT => CONNECT handle 0x64f4b0; line 1046 (connection #-5000)
      * Rebuilt URL to: http://MTEST/
      * Added connection 0. The cache now contains 1 members
      * STATE: CONNECT => WAITRESOLVE handle 0x64f4b0; line 1083
      (connection #0)
      *   Trying 127.0.0.2...
      * STATE: WAITRESOLVE => WAITCONNECT handle 0x64f4b0; line 1163
      (connection #0)
      *   Trying 127.0.0.3...
      * connect to 127.0.0.2 port 80 failed: Connection refused
      *   Trying 127.0.0.3...
      * connect to 127.0.0.3 port 80 failed: Connection refused
      *   Trying 127.0.0.4...
      * connect to 127.0.0.3 port 80 failed: Connection refused
      *   Trying 127.0.0.4...
      * connect to 127.0.0.4 port 80 failed: Connection refused
      * connect to 127.0.0.4 port 80 failed: Connection refused
      * Failed to connect to MTEST port 80: Connection refused
      * Closing connection 0
      * The cache now contains 0 members
      * Expire cleared
      curl: (7) Failed to connect to MTEST port 80: Connection refused
      
      The bug was born in commit bagder/curl@2d435c7.
      059b3a57
  2. Mar 15, 2015
  3. Mar 14, 2015
    • Tobias Stoeckmann's avatar
      hostip: Fix signal race in Curl_resolv_timeout. · 851c2926
      Tobias Stoeckmann authored
      A signal handler for SIGALRM is installed in Curl_resolv_timeout. It is
      configured to interrupt system calls and uses siglongjmp to return into
      the function if alarm() goes off.
      
      The signal handler is installed before curl_jmpenv is initialized.
      This means that an already installed alarm timer could trigger the
      newly installed signal handler, leading to undefined behavior when it
      accesses the uninitialized curl_jmpenv.
      
      Even if there is no previously installed alarm available, the code in
      Curl_resolv_timeout itself installs an alarm before the environment is
      fully set up. If the process is sent into suspend right after that, the
      signal handler could be called too early as in previous scenario.
      
      To fix this, the signal handler should only be installed and the alarm
      timer only be set after sigsetjmp has been called.
      851c2926
    • Daniel Stenberg's avatar
      http2: detect prematures close without data transfered · 0cf649d9
      Daniel Stenberg authored
      ... by using the regular Curl_http_done() method which checks for
      that. This makes test 1801 fail consistently with error 56 (which seems
      fine) to that test is also updated here.
      
      Reported-by: Ben Darnell
      Bug: https://github.com/bagder/curl/issues/166
      0cf649d9
  4. Mar 13, 2015
  5. Mar 12, 2015
  6. Mar 11, 2015
  7. Mar 10, 2015
  8. Mar 09, 2015
  9. Mar 07, 2015
  10. Mar 06, 2015
  11. Mar 05, 2015