github-actions[bot]
commented
1 month ago Thank you for your feedback. Tagging and routing to the team member best able to assist.
Open ArneWouters opened 1 month ago
github-actions[bot]
commented
1 month ago Thank you for your feedback. Tagging and routing to the team member best able to assist.
LarryOsterman
commented
1 month ago I believe that the root cause of this may be in curl.
The code which called free is from lib\vtls\schannel.c.
Note the call to curlx_unicodefree below:
static void schannel_session_free(void *sessionid, size_t idsize)
{
/* this is expected to be called under sessionid lock */
struct Curl_schannel_cred *cred = sessionid;
(void)idsize;
if(cred) {
cred->refcount--;
if(cred->refcount == 0) {
s_pSecFn->FreeCredentialsHandle(&cred->cred_handle);
curlx_unicodefree(cred->sni_hostname);
#ifdef HAS_CLIENT_CERT_PATH
if(cred->client_cert_store) {
CertCloseStore(cred->client_cert_store, 0);
cred->client_cert_store = NULL;
}
#endif
Curl_safefree(cred);
}
}
}Looking at that code (in the file curl_multibyte.h) we find the following code:
#define curlx_unicodefree(ptr) \
do { \
if(ptr) { \
(free)(ptr); \
(ptr) = NULL; \
} \
} while(0)I believe that unilaterally calls the free function, not the user configured free function.
So I strongly suspect that the root cause of this issue is in libcurl and not in the Azure SDK for C++.
But I'm more than willing to be proven wrong.
LarryOsterman
commented
1 month ago Looking deeper, it appears that I may be wrong - the cred->sni_hostname is created using curlx_convert_UTF8_to_tchar which uses malloc directly and not the custom allocator.
However Curl_safefree may have a similar problem, which is more likely to be the problem.
ArneWouters
commented
1 month ago Ah, it indeed mentions at the top of curl_multibyte.h that all curlx functions do not use the configured memory allocators. I completely missed that but that already explains one thing. So far I tried to use the internal memory debugging tools from curl but I haven't gotten them to work with our vcpkg pipeline yet.
LarryOsterman
commented
1 month ago Ok, given this, I believe we can close this out, unless there is something else we can help you with.
ArneWouters
commented
1 month ago Still having the crash that we can't explain though, is there anything that we can still investigate or try? We can also log an issue on the curl github if you think this is not related to the SDK.
LarryOsterman
commented
1 month ago I'm not 100% sure, to be honest. The symptoms are those of a heap corruption, but it's not clear where the corruption is coming from.
Have you tried using AddressSanitizer on your reproduction scenario? I've found it's incredibly helpful for this kind of problem.
Describe the bug We are getting a
_CrtIsValidHeapPointer(block)assertion when using the SDK with curl on windows. The issue only occurs when theCleanupThreadfunction is executed. At first we thought the issue was due to the library not using our custom memory allocators so we fixed that by setting them at the beginning of the program. Looking at the Stack Trace, it seems that the free is not using our custom free though. We're not sure why that is happening. Curl is definitely using our custom alloc and free functions during the executions before the cleanup. We have also noticed that the SDK statically initializes curl which could lead to a deadlock on windows according to the documentation ofcurl_global_init.Exception or Stack Trace
To Reproduce We build the SDK with vcpkg, we have tried linking curl statically and dynamically into the SDK, both are giving us this problem. We employ an in house memory allocation solution. As a workaround we are currently using the SDK with WinHTTP, which works fine.
Code Snippet
Expected behavior We expect it to work without throwing an exception.
Screenshots N/A
Setup (please complete the following information):
Additional context Logging output
Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report