Skip to content

Find files in Windows#1

Merged
whoshuu merged 1 commit intowhoshuu:masterfrom
jgsogo:msvc2015
Oct 13, 2015
Merged

Find files in Windows#1
whoshuu merged 1 commit intowhoshuu:masterfrom
jgsogo:msvc2015

Conversation

@jgsogo
Copy link

@jgsogo jgsogo commented Oct 13, 2015

Using C++ Request from @skystrife I come accross an issue related to installation in Windows (it may happen also in other platforms). With this fix the system is able to found the files to install.

I'm pushing the PR here because it is the repo being used as dependency in skystrife/cpr, but I'll try to push it also upstream to bagder/curl.

Thanks!

@whoshuu
Copy link
Owner

whoshuu commented Oct 13, 2015

Thanks for the PR @jgsogo. That's an interesting find. CURL_BINARY_DIR and CMAKE_BINARY_DIR should be the same, but I guess they aren't. I'll run this through appveyor and let you know if it's good to go.

@whoshuu
Copy link
Owner

whoshuu commented Oct 13, 2015

Looks good to me. Thanks!

whoshuu added a commit that referenced this pull request Oct 13, 2015
@whoshuu whoshuu merged commit 6520005 into whoshuu:master Oct 13, 2015
@whoshuu
Copy link
Owner

whoshuu commented Oct 13, 2015

The change is reflected in the main C++ Requests repository here: libcpr/cpr@f9a3159. Note, the fork you're using from @skystrife will have to pull in the changes before you see them. Alternatively you can fork the main repository yourself.

jgsogo pushed a commit to jgsogo/curl that referenced this pull request Oct 13, 2015
Visual Studio complains with a message box:

"Run-Time Check Failure whoshuu#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 curl#387
@jgsogo
Copy link
Author

jgsogo commented Oct 13, 2015

Thanks! I don't know why I was using @skystrife's repo, maybe because I'm interested in META and I had a look at his profile... I'll move to yours.

jgsogo pushed a commit to jgsogo/curl that referenced this pull request Oct 19, 2015
Visual Studio complains with a message box:

"Run-Time Check Failure whoshuu#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 curl#387
whoshuu pushed a commit that referenced this pull request Nov 7, 2016
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, curl#2, etc) that data is unsanitized
until I finish a fix.

Bug: curl#624
Reported-by: Octavio Schroeder
whoshuu pushed a commit that referenced this pull request Nov 7, 2016
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
    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
    #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 ()
 #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

Fixes curl#1083
whoshuu pushed a commit that referenced this pull request Jan 15, 2017
CID 1397391 (#1 of 1): Unchecked return value (CHECKED_RETURN)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants