azure-sdk-for-cpp icon indicating copy to clipboard operation
azure-sdk-for-cpp copied to clipboard

Can't run example blob due to BlobContainerClient crashing in LogOptions set(const set& _Right)

Open jamwhy opened this issue 1 year ago • 3 comments

Describe the bug

Unhandled exception thrown: read access violation. _Right_scary->_Myhead was 0x1.

Exception or Stack Trace

    template <_Strategy _Strat>
    void _Copy(const _Tree& _Right) { // copy or move entire tree from _Right
        const auto _Scary        = _Get_scary();
        const auto _Right_scary  = _Right._Get_scary();
        _Scary->_Myhead->_Parent = _Copy_nodes<_Strat>(_Right_scary->_Myhead->_Parent, _Scary->_Myhead); <---- exception here

Disassembly of the call to the copy above:
pvcl_test.exe!Azure::Core::Http::Policies::LogOptions::LogOptions(void):
00007FF6B3B0BBD0  mov         qword ptr [rsp+8],rcx  
00007FF6B3B0BBD5  push        rdi  
00007FF6B3B0BBD6  sub         rsp,30h  
00007FF6B3B0BBDA  mov         rax,qword ptr [this]  
00007FF6B3B0BBDF  mov         qword ptr [rsp+20h],rax  
00007FF6B3B0BBE4  mov         rdx,qword ptr [__imp_Azure::Core::Http::Policies::_detail::g_defaultAllowedHttpQueryParameters (07FF6B48F9448h)]  
00007FF6B3B0BBEB  mov         rcx,qword ptr [rsp+20h]  
00007FF6B3B0BBF0  call        std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::set<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > (07FF6B39AA80Dh)  



Executing this call from the example:
auto containerClient = BlobContainerClient::CreateFromConnectionString(GetConnectionString(), "sandbox");

azure_test.exe!std::_Tree<std::_Tset_traits<std::string,std::less<std::string>,std::allocator<std::string>,0>>::_Copy<0>(const std::_Tree<std::_Tset_traits<std::string,std::less<std::string>,std::allocator<std::string>,0>> & _Right) Line 1633	C++
 	azure_test.exe!std::_Tree<std::_Tset_traits<std::string,std::less<std::string>,std::allocator<std::string>,0>>::_Tree<std::_Tset_traits<std::string,std::less<std::string>,std::allocator<std::string>,0>><std::allocator<std::_Tree_node<std::string,void *>>>(const std::_Tree<std::_Tset_traits<std::string,std::less<std::string>,std::allocator<std::string>,0>> & _Right, std::allocator<std::_Tree_node<std::string,void *>> && _Al) Line 898	C++
 	azure_test.exe!std::set<std::string,std::less<std::string>,std::allocator<std::string>>::set<std::string,std::less<std::string>,std::allocator<std::string>>(const std::set<std::string,std::less<std::string>,std::allocator<std::string>> & _Right) Line 87	C++
 	azure_test.exe!Azure::Core::Http::Policies::LogOptions::LogOptions()	C++
 	azure_test.exe!Azure::Core::_internal::ClientOptions::ClientOptions() Line 56	C++
 	[External Code]	

To Reproduce Build and run the example from here: https://github.com/Azure/azure-sdk-for-cpp or here: https://github.com/Azure/azure-sdk-for-cpp/blob/main/sdk/storage/azure-storage-blobs/samples/blob_getting_started.cpp

I tried this with both examples, both produce the same results. The LogOptions have some issue when the ClientOptions() = default; is called creating a BlobContainerClient

Code Snippet auto containerClient = BlobContainerClient::CreateFromConnectionString(GetConnectionString(), "sandbox");

Expected behavior Don't crash

Setup (please complete the following information):

  • OS: Windows
  • IDE : MSVC 2022
  • Revision: 576379156e82da642f8d1834220876759f13534d Author: Timur Chernykh [email protected] Date: 7/5/2024 11:07:14 AM Message: [libcgroup] added new port (#39647)

jamwhy avatar Jul 31 '24 01:07 jamwhy

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Jinming-Hu @microzchang @vinjiang.

github-actions[bot] avatar Jul 31 '24 01:07 github-actions[bot]

Crashed when constructing the std::set here.

https://github.com/Azure/azure-sdk-for-cpp/blob/20e3bd3ff442f0ce018e9f99542ba22704b1d091/sdk/core/azure-core/inc/azure/core/http/policies/policy.hpp#L149

Is there anything special about the global variable? @RickWinter Can your team take a look?

Jinming-Hu avatar Aug 01 '24 03:08 Jinming-Hu

@ahsonkhan can you help out investigating this issue.

RickWinter avatar Aug 07 '24 15:08 RickWinter

@ahsonkhan @RickWinter Is there any update on this issue?

Justsvetoslavov avatar Jan 07 '25 12:01 Justsvetoslavov

To whom it may concern (cc: @jamwhy , @ahsonkhan),

I managed to resolve the issue I was experiencing with the BlobContainerClient crashing in LogOptions::set(const set&). After some investigation, I found that the problem stemmed from a mismatch between static and dynamic linking in my project.

Specifically, the dynamic linking (.dll) was being taken from vcpkg, as it was connected with my project. However, this behavior was unintended and led to runtime library inconsistencies, causing crashes. By switching to static linking exclusively for the project, the issue no longer occurred.

I believe this solution works because static linking ensures consistency in runtime behavior, avoiding potential problems like:

  • Runtime Library Mismatch: When mixing static (/MT or /MTd) and dynamic (/MD or /MDd) runtime libraries, containers like std::set may encounter memory management issues, causing crashes during operations like assignment or clearing.
  • Initialization Order Issues: When combining static and dynamic linking, global/static variables like _detail::g_defaultAllowedHttpQueryParameters and _detail::g_defaultAllowedHttpHeaders can suffer from initialization order problems, leading to undefined behavior.

Switching to static linking resolved these concerns by ensuring:

  • Consistent runtime library usage across the project.
  • Proper initialization of all objects within the same binary.

For others facing similar issues, I recommend verifying runtime library settings and ensuring they are consistent across all components of the build. Additionally, check for unintended dynamic linking caused by dependency managers like vcpkg. If dynamic linking is necessary, careful attention must be given to runtime library selection and initialization order.

I hope this insight helps others encountering similar problems!

Justsvetoslavov avatar Jan 24 '25 10:01 Justsvetoslavov