docs/libcurl/libcurl.m4 bug #1

dwlocks · 2010-10-01T23:14:39Z

The LIBCURL_CHECK_CONFIG macro has a bug such that it uses the value passed in --with-libcurl= as a prefix instead of as a lib directory. so the result of passing "/usr/lib" is searching for curl in /usr/lib/lib.

The patch fixes that.

The second patch fixes some odd, perhaps obsolete uses of AC_PATH_PROG()

Let me know if it needs modification.

The --with-libcurl option added by this macro requests a library dir, but used the value as a prefix. Adding a variable to hold `dirname $withval` solves the problem.

bagder · 2010-10-05T20:54:04Z

dealt with these issues in the bug tracker

Visual Studio complains with a message box: "Run-Time Check Failure #1 - A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example: char c = (i & 0xFF); Changing the code in this way will not affect the quality of the resulting optimized code." This is because only 'val' is cast to unsigned char, so the "& 0xff" has no effect.

Visual Studio complains with a message box: "Run-Time Check Failure #1 - A cast to a smaller data type has caused a loss of data. If this was intentional, you should mask the source of the cast with the appropriate bitmask. For example: char c = (i & 0xFF); Changing the code in this way will not affect the quality of the resulting optimized code." This is because only 'val' is cast to unsigned char, so the "& 0xff" has no effect. Closes #387

Due to path separators being incorrectly sanitized in --output pathnames, eg -o c:\foo => c__foo This is a partial revert of 3017d8a until I write a proper fix. The remote-name will continue to be sanitized, but if the user specified an --output with string replacement (#1, #2, etc) that data is unsanitized until I finish a fix. Bug: #624 Reported-by: Octavio Schroeder

This prevents a crash in the following scenario: 2 (or more) requests are made to the same host and pipelining is enabled. The first request times out. Curl_done will return early in this block since conn->send_pipe->size == 1: if((conn->send_pipe->size + conn->recv_pipe->size != 0 && !data->set.reuse_forbid && !conn->bits.close)) { /* Stop if pipeline is not empty and we do not have to close connection. */ DEBUGF(infof(data, "Connection still in use, no more Curl_done now!\n")); return CURLE_OK; } When the second one fails it will not return early and will in fact call Curl_disconnect which will free the connection. When curl_easy_cleanup is called on the first request his easy_conn pointer will be a dangling pointer and the app will crash. ASAN output: ==7245==ERROR: AddressSanitizer: heap-use-after-free on address 0xda366d80 at pc 0x986d05b bp 0xd94b16d8 sp 0xd94b16c0 READ of size 4 at 0xda366d80 thread T16 (RESOURCE_HTTP) #0 0x986d05a in curl_multi_remove_handle curl#1 0x98a3e2b in Curl_close curl#2 0x985abb5 in curl_easy_cleanup curl#3 0x9777302 in <application frames> curl#4 0xf7b2a016 in __asan::AsanThread::ThreadStart(unsigned long) curl#5 0xf7b16f40 in asan_thread_start(void*) curl#6 0xf7a971a9 in start_thread curl#7 0xf681b02d in clone 0xda366d80 is located 0 bytes inside of 1100-byte region [0xda366d80,0xda3671cc) freed by thread T16 (RESOURCE_HTTP) here: #0 0xf7b1fa5a in free curl#1 0x98b5948 in Curl_disconnect curl#2 0x98d067d in Curl_done curl#3 0x9875a61 in curl_multi_perform curl#4 0x9758a71 in <application frames> curl#5 0xf7b2a016 in __asan::AsanThread::ThreadStart(unsigned long) curl#6 0xf681b02d in clone

In short the easy handle needs to be disconnected from its connection at this point since the connection still is serving other easy handles. In our app we can reliably reproduce a crash in our http2 stress test that is fixed by this change. I can't easily reproduce the same test in a small example. This is the gdb/asan output: ==11785==ERROR: AddressSanitizer: heap-use-after-free on address 0xe9f4fb80 at pc 0x09f41f19 bp 0xf27be688 sp 0xf27be67c READ of size 4 at 0xe9f4fb80 thread T13 (RESOURCE_HTTP) #0 0x9f41f18 in curl_multi_remove_handle /path/to/source/3rdparty/curl/lib/multi.c:666 0xe9f4fb80 is located 0 bytes inside of 1128-byte region [0xe9f4fb80,0xe9f4ffe8) freed by thread T13 (RESOURCE_HTTP) here: #0 0xf7b1b5c2 in __interceptor_free /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_malloc_linux.cc:45 curl#1 0x9f7862d in conn_free /path/to/source/3rdparty/curl/lib/url.c:2808 curl#2 0x9f78c6a in Curl_disconnect /path/to/source/3rdparty/curl/lib/url.c:2876 curl#3 0x9f41b09 in multi_done /path/to/source/3rdparty/curl/lib/multi.c:615 curl#4 0x9f48017 in multi_runsingle /path/to/source/3rdparty/curl/lib/multi.c:1896 curl#5 0x9f490f1 in curl_multi_perform /path/to/source/3rdparty/curl/lib/multi.c:2123 curl#6 0x9c4443c in perform /path/to/source/src/net/resourcemanager/ResourceManagerCurlThread.cpp:854 curl#7 0x9c445e0 in ... curl#8 0x9c4cf1d in ... curl#9 0xa2be6b5 in ... curl#10 0xf7aa5780 in asan_thread_start /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 curl#11 0xf4d3a16d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe716d) previously allocated by thread T13 (RESOURCE_HTTP) here: #0 0xf7b1ba27 in __interceptor_calloc /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_malloc_linux.cc:70 curl#1 0x9f7dfa6 in allocate_conn /path/to/source/3rdparty/curl/lib/url.c:3904 curl#2 0x9f88ca0 in create_conn /path/to/source/3rdparty/curl/lib/url.c:5797 curl#3 0x9f8c928 in Curl_connect /path/to/source/3rdparty/curl/lib/url.c:6438 curl#4 0x9f45a8c in multi_runsingle /path/to/source/3rdparty/curl/lib/multi.c:1411 curl#5 0x9f490f1 in curl_multi_perform /path/to/source/3rdparty/curl/lib/multi.c:2123 curl#6 0x9c4443c in perform /path/to/source/src/net/resourcemanager/ResourceManagerCurlThread.cpp:854 curl#7 0x9c445e0 in ... curl#8 0x9c4cf1d in ... curl#9 0xa2be6b5 in ... curl#10 0xf7aa5780 in asan_thread_start /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 curl#11 0xf4d3a16d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe716d) SUMMARY: AddressSanitizer: heap-use-after-free /path/to/source/3rdparty/curl/lib/multi.c:666 in curl_multi_remove_handle Shadow bytes around the buggy address: 0x3d3e9f20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f50: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa 0x3d3e9f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x3d3e9f70:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fa0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11785==ABORTING Thread 14 "RESOURCE_HTTP" received signal SIGABRT, Aborted. [Switching to Thread 0xf27bfb40 (LWP 12324)] 0xf7fd8be9 in __kernel_vsyscall () (gdb) bt

In short the easy handle needs to be disconnected from its connection at this point since the connection still is serving other easy handles. In our app we can reliably reproduce a crash in our http2 stress test that is fixed by this change. I can't easily reproduce the same test in a small example. This is the gdb/asan output: ==11785==ERROR: AddressSanitizer: heap-use-after-free on address 0xe9f4fb80 at pc 0x09f41f19 bp 0xf27be688 sp 0xf27be67c READ of size 4 at 0xe9f4fb80 thread T13 (RESOURCE_HTTP) #0 0x9f41f18 in curl_multi_remove_handle /path/to/source/3rdparty/curl/lib/multi.c:666 0xe9f4fb80 is located 0 bytes inside of 1128-byte region [0xe9f4fb80,0xe9f4ffe8) freed by thread T13 (RESOURCE_HTTP) here: #0 0xf7b1b5c2 in __interceptor_free /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_malloc_linux.cc:45 curl#1 0x9f7862d in conn_free /path/to/source/3rdparty/curl/lib/url.c:2808 curl#2 0x9f78c6a in Curl_disconnect /path/to/source/3rdparty/curl/lib/url.c:2876 curl#3 0x9f41b09 in multi_done /path/to/source/3rdparty/curl/lib/multi.c:615 curl#4 0x9f48017 in multi_runsingle /path/to/source/3rdparty/curl/lib/multi.c:1896 curl#5 0x9f490f1 in curl_multi_perform /path/to/source/3rdparty/curl/lib/multi.c:2123 curl#6 0x9c4443c in perform /path/to/source/src/net/resourcemanager/ResourceManagerCurlThread.cpp:854 curl#7 0x9c445e0 in ... curl#8 0x9c4cf1d in ... curl#9 0xa2be6b5 in ... curl#10 0xf7aa5780 in asan_thread_start /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 curl#11 0xf4d3a16d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe716d) previously allocated by thread T13 (RESOURCE_HTTP) here: #0 0xf7b1ba27 in __interceptor_calloc /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_malloc_linux.cc:70 curl#1 0x9f7dfa6 in allocate_conn /path/to/source/3rdparty/curl/lib/url.c:3904 curl#2 0x9f88ca0 in create_conn /path/to/source/3rdparty/curl/lib/url.c:5797 curl#3 0x9f8c928 in Curl_connect /path/to/source/3rdparty/curl/lib/url.c:6438 curl#4 0x9f45a8c in multi_runsingle /path/to/source/3rdparty/curl/lib/multi.c:1411 curl#5 0x9f490f1 in curl_multi_perform /path/to/source/3rdparty/curl/lib/multi.c:2123 curl#6 0x9c4443c in perform /path/to/source/src/net/resourcemanager/ResourceManagerCurlThread.cpp:854 curl#7 0x9c445e0 in ... curl#8 0x9c4cf1d in ... curl#9 0xa2be6b5 in ... curl#10 0xf7aa5780 in asan_thread_start /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 curl#11 0xf4d3a16d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe716d) SUMMARY: AddressSanitizer: heap-use-after-free /path/to/source/3rdparty/curl/lib/multi.c:666 in curl_multi_remove_handle Shadow bytes around the buggy address: 0x3d3e9f20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f50: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa 0x3d3e9f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x3d3e9f70:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fa0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11785==ABORTING Thread 14 "RESOURCE_HTTP" received signal SIGABRT, Aborted. [Switching to Thread 0xf27bfb40 (LWP 12324)] 0xf7fd8be9 in __kernel_vsyscall () (gdb) bt #0 0xf7fd8be9 in __kernel_vsyscall () curl#1 0xf4c7ee89 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54 curl#2 0xf4c803e7 in __GI_abort () at abort.c:89 curl#3 0xf7b2ef2e in __sanitizer::Abort () at /opt/toolchain/src/gcc-6.2.0/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:122 curl#4 0xf7b262fa in __sanitizer::Die () at /opt/toolchain/src/gcc-6.2.0/libsanitizer/sanitizer_common/sanitizer_common.cc:145 curl#5 0xf7b21ab3 in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0xf27be171, __in_chrg=<optimized out>) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_report.cc:689 curl#6 0xf7b214a5 in __asan::ReportGenericError (pc=166993689, bp=4068206216, sp=4068206204, addr=3925146496, is_write=false, access_size=4, exp=0, fatal=true) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_report.cc:1074 curl#7 0xf7b21fce in __asan::__asan_report_load4 (addr=3925146496) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_rtl.cc:129 curl#8 0x09f41f19 in curl_multi_remove_handle (multi=0xf3406080, data=0xde582400) at /path/to/source3rdparty/curl/lib/multi.c:666 curl#9 0x09f6b277 in Curl_close (data=0xde582400) at /path/to/source3rdparty/curl/lib/url.c:415 curl#10 0x09f3354e in curl_easy_cleanup (data=0xde582400) at /path/to/source3rdparty/curl/lib/easy.c:860 curl#11 0x09c6de3f in ... curl#12 0x09c378c5 in ... curl#13 0x09c48133 in ... curl#14 0x09c4d092 in ... curl#15 0x0a2be6b6 in ... curl#16 0xf7aa5781 in asan_thread_start (arg=0xf2d22938) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 curl#17 0xf5de52b5 in start_thread (arg=0xf27bfb40) at pthread_create.c:333 curl#18 0xf4d3a16e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:114

In short the easy handle needs to be disconnected from its connection at this point since the connection still is serving other easy handles. In our app we can reliably reproduce a crash in our http2 stress test that is fixed by this change. I can't easily reproduce the same test in a small example. This is the gdb/asan output: ==11785==ERROR: AddressSanitizer: heap-use-after-free on address 0xe9f4fb80 at pc 0x09f41f19 bp 0xf27be688 sp 0xf27be67c READ of size 4 at 0xe9f4fb80 thread T13 (RESOURCE_HTTP) #0 0x9f41f18 in curl_multi_remove_handle /path/to/source/3rdparty/curl/lib/multi.c:666 0xe9f4fb80 is located 0 bytes inside of 1128-byte region [0xe9f4fb80,0xe9f4ffe8) freed by thread T13 (RESOURCE_HTTP) here: #0 0xf7b1b5c2 in __interceptor_free /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_malloc_linux.cc:45 #1 0x9f7862d in conn_free /path/to/source/3rdparty/curl/lib/url.c:2808 #2 0x9f78c6a in Curl_disconnect /path/to/source/3rdparty/curl/lib/url.c:2876 #3 0x9f41b09 in multi_done /path/to/source/3rdparty/curl/lib/multi.c:615 #4 0x9f48017 in multi_runsingle /path/to/source/3rdparty/curl/lib/multi.c:1896 #5 0x9f490f1 in curl_multi_perform /path/to/source/3rdparty/curl/lib/multi.c:2123 #6 0x9c4443c in perform /path/to/source/src/net/resourcemanager/ResourceManagerCurlThread.cpp:854 #7 0x9c445e0 in ... #8 0x9c4cf1d in ... #9 0xa2be6b5 in ... #10 0xf7aa5780 in asan_thread_start /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 #11 0xf4d3a16d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe716d) previously allocated by thread T13 (RESOURCE_HTTP) here: #0 0xf7b1ba27 in __interceptor_calloc /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_malloc_linux.cc:70 #1 0x9f7dfa6 in allocate_conn /path/to/source/3rdparty/curl/lib/url.c:3904 #2 0x9f88ca0 in create_conn /path/to/source/3rdparty/curl/lib/url.c:5797 #3 0x9f8c928 in Curl_connect /path/to/source/3rdparty/curl/lib/url.c:6438 #4 0x9f45a8c in multi_runsingle /path/to/source/3rdparty/curl/lib/multi.c:1411 #5 0x9f490f1 in curl_multi_perform /path/to/source/3rdparty/curl/lib/multi.c:2123 #6 0x9c4443c in perform /path/to/source/src/net/resourcemanager/ResourceManagerCurlThread.cpp:854 #7 0x9c445e0 in ... #8 0x9c4cf1d in ... #9 0xa2be6b5 in ... #10 0xf7aa5780 in asan_thread_start /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 #11 0xf4d3a16d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe716d) SUMMARY: AddressSanitizer: heap-use-after-free /path/to/source/3rdparty/curl/lib/multi.c:666 in curl_multi_remove_handle Shadow bytes around the buggy address: 0x3d3e9f20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f50: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa 0x3d3e9f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x3d3e9f70:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9f90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fa0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3d3e9fc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11785==ABORTING Thread 14 "RESOURCE_HTTP" received signal SIGABRT, Aborted. [Switching to Thread 0xf27bfb40 (LWP 12324)] 0xf7fd8be9 in __kernel_vsyscall () (gdb) bt #0 0xf7fd8be9 in __kernel_vsyscall () #1 0xf4c7ee89 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #2 0xf4c803e7 in __GI_abort () at abort.c:89 #3 0xf7b2ef2e in __sanitizer::Abort () at /opt/toolchain/src/gcc-6.2.0/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:122 #4 0xf7b262fa in __sanitizer::Die () at /opt/toolchain/src/gcc-6.2.0/libsanitizer/sanitizer_common/sanitizer_common.cc:145 #5 0xf7b21ab3 in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0xf27be171, __in_chrg=<optimized out>) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_report.cc:689 #6 0xf7b214a5 in __asan::ReportGenericError (pc=166993689, bp=4068206216, sp=4068206204, addr=3925146496, is_write=false, access_size=4, exp=0, fatal=true) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_report.cc:1074 #7 0xf7b21fce in __asan::__asan_report_load4 (addr=3925146496) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_rtl.cc:129 #8 0x09f41f19 in curl_multi_remove_handle (multi=0xf3406080, data=0xde582400) at /path/to/source3rdparty/curl/lib/multi.c:666 #9 0x09f6b277 in Curl_close (data=0xde582400) at /path/to/source3rdparty/curl/lib/url.c:415 #10 0x09f3354e in curl_easy_cleanup (data=0xde582400) at /path/to/source3rdparty/curl/lib/easy.c:860 #11 0x09c6de3f in ... #12 0x09c378c5 in ... #13 0x09c48133 in ... #14 0x09c4d092 in ... #15 0x0a2be6b6 in ... #16 0xf7aa5781 in asan_thread_start (arg=0xf2d22938) at /opt/toolchain/src/gcc-6.2.0/libsanitizer/asan/asan_interceptors.cc:226 #17 0xf5de52b5 in start_thread (arg=0xf27bfb40) at pthread_create.c:333 #18 0xf4d3a16e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:114 Fixes #1083

CID 1397391 (#1 of 1): Unchecked return value (CHECKED_RETURN)

dwlocks added 2 commits October 1, 2010 15:27

docs/libcurl/libcurl.m4: LIBCURL_CHECK_CONFIG --with-libcurl

1fa23d4

The --with-libcurl option added by this macro requests a library dir, but used the value as a prefix. Adding a variable to hold `dirname $withval` solves the problem.

docs/libcurl/libcurl.m4: Fix AC_PATH_PROG() usages.

1f85c89

victorcui0327 mentioned this pull request Aug 10, 2015

HTTP proxy tunnel can not work after upgrade to 7.42.1 from 7.36 under NTLM(GSS) #369

Closed

MarcelRaad mentioned this pull request Aug 18, 2015

inet_pton.c: Fix MSVC run-time check failure #387

Closed

iboukris mentioned this pull request Sep 15, 2015

Inifinite loop during NTLM authentication #435

Closed

ghost mentioned this pull request Jan 17, 2016

Infinite loop at function Curl_llist_destroy() #604

Closed

Andersbakken mentioned this pull request Mar 1, 2016

If Curl_done is called with premature == TRUE we can't pipeline #690

Closed

ghost mentioned this pull request May 17, 2016

TCP connection reuse issue with curl 7.48.0 #810

Closed

JackChen255 mentioned this pull request Jun 20, 2016

libcurl crashes at fwrite() when I upload a file #886

Closed

arekm mentioned this pull request Jul 19, 2016

SSL_COMP_free_compression_methods freeing harms other openssl users in single binary (php in this case) #905

Closed

Andersbakken mentioned this pull request Oct 20, 2016

Fix a double-free for curl_multi_remove_handle #1083

Closed

afrind mentioned this pull request Nov 3, 2016

HTTP/2 downloads slower with default flow control #1102

Closed

dzatvorniy mentioned this pull request Nov 8, 2016

curl crash due to hostent has h_name == NULL #1114

Closed

usergoodvery mentioned this pull request Nov 9, 2016

valgrind noise... #1117

Closed

Andersbakken mentioned this pull request Nov 15, 2016

Fix crashes when http2 parent stream gets aborted. #1125

Closed

bagder added a commit that referenced this pull request Dec 20, 2016

ssh: inhibit coverity warning with (void)

f44cf79

CID 1397391 (#1 of 1): Unchecked return value (CHECKED_RETURN)

41405465 mentioned this pull request Dec 28, 2016

the libcurl crash,when the url is invalid #1179

Closed

cam888eron mentioned this pull request Feb 8, 2017

Fix tiny memory leak upon edge case connecting to proxy #1255

Closed

ismail mentioned this pull request Feb 23, 2017

Set CHARSET & LANG to UTF-8 compatible values for idn tests #1283

Closed

lietusme mentioned this pull request Feb 27, 2017

HTTPS upload hangs using Windows Server 2008 #1294

Closed

Pwera mentioned this pull request Apr 20, 2017

UNINITIALIZED READ" when using POST/GET on Windows 7 #1434

Closed

jlspyaozhongkai mentioned this pull request Jun 6, 2017

libcur not read the socket when EPOLLIN event，caused epoll event deadloop (multi interface + epoll) #1545

Closed

dertin mentioned this pull request Jun 19, 2017

OpenSSL headers and library versions do not match #1583

Closed

Jyoti-bdk mentioned this pull request Aug 12, 2017

Libcurl (7.54.0) related stack corruption,memory leak on FreeBSD 6 #1768

Closed

marcialpaulg mentioned this pull request Sep 23, 2017

cgi:error AH01215 #1913

Closed

hundan2020 mentioned this pull request Nov 10, 2017

curl -b/--cookie option failed to send cookie from a file #2066

Closed

rb07 mentioned this pull request Dec 1, 2017

Digest authentication ignores changed nonce #2136

Closed

jlubinda mentioned this pull request Jan 10, 2018

Double Posting of Request #2228

Closed

vvxvv mentioned this pull request Jan 20, 2018

command line arguments parse error #2254

Closed

dhakiptk mentioned this pull request Feb 5, 2018

http2 assert drain_total and state.drain gets out of sync #1680

Closed

coffeegist mentioned this pull request Mar 14, 2018

User-Agent not set when proxying SSL request #2381

Closed

kekePower mentioned this pull request Mar 18, 2018

test340 fails with curl 7.54.1 on Mageia 6 #2395

Closed

asheikm mentioned this pull request Mar 20, 2018

old libcurl segfault in OpenSSL #2409

Closed

rouault mentioned this pull request Apr 7, 2018

Random crash in Curl_thread_destroy #2469

Closed

vince166 mentioned this pull request Apr 25, 2018

libcurl crashes when reusing easy_handle with FTPS sites #2530

Closed

tokers mentioned this pull request May 7, 2018

a segmentation fault might occur when using --limit-rate option #2552

Closed

This was referenced May 15, 2018

DNS server update causes problem #2251

Closed

Periodic calls to curl_easy_perform apparently causing open socket descriptors on DNS resolution failure. #2574

Closed

ebadf00d mentioned this pull request May 29, 2018

Got warning when build on debian 9 ppc64le (curl 7.60.0) #2617

Closed

jiandong1997 mentioned this pull request Jul 19, 2018

Curl with Cyassl and curl_multi_socket_action #2759

Closed

TithiK mentioned this pull request Jul 20, 2018

--max-time option NOT working #2770

Closed

TithiK mentioned this pull request Jul 31, 2018

--max-time option NOT working #2814

Closed

Desperado17 mentioned this pull request Aug 1, 2018

AddressSanitizer finding in Curl-7.54.0 #2824

Closed

zagor mentioned this pull request Oct 1, 2018

HTTP Strict Transport Security (HSTS) using libhsts #2682

Closed

dinama mentioned this pull request Oct 15, 2018

7.61.1 crash on __write_nocancel:libpthread #3139

Closed

This was referenced Oct 28, 2018

mprintf: Fix integer overflow #3183

Closed

mprintf: Avoid integer overflow warning from clang #3184

Closed

Silence integer overflow in Curl_hash_str() #3185

Closed

abraunegg mentioned this pull request Nov 9, 2018

Files will not download when using curl 7.62.0 #3253

Closed

ArayChou mentioned this pull request Nov 15, 2018

Connect to a localhost port which does not exists, may choose the destination port as source port #3272

Closed

lock bot locked as resolved and limited conversation to collaborators Jan 20, 2019

This pull request was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs/libcurl/libcurl.m4 bug #1

docs/libcurl/libcurl.m4 bug #1

dwlocks commented Oct 1, 2010

bagder commented Oct 5, 2010

docs/libcurl/libcurl.m4 bug #1

docs/libcurl/libcurl.m4 bug #1

Conversation

dwlocks commented Oct 1, 2010

bagder commented Oct 5, 2010