[BUG] Incorrect use of new and delete, address sanitizer complains #648
Description
Project
MSIX SDK
Describe the bug
Address sanitizer found that pointer to array is deleted incorrectly. It looks like the arrays are allocated with ::operator new(size), and later deleted with ::operator delete(ptr) where size is not known. This results in the address sanitizer reports like the one below:
object passed to delete has wrong type:
4 │ size of the allocated type: 34 bytes;
5 │ size of the deallocated type: 1 bytes.
#0 0x557eb3c0496f in operator delete(void*, unsigned long) (test_executable+0x2df196f)
7 │ #1 0x557eb4d47ccb in MSIX::XercesXMLBytePtr::InternalRelease() .../src/msix/PAL/XML/xerces-c/XmlObject.cpp:226
8 │ #2 0x557eb4d47c65 in MSIX::XercesXMLBytePtr::~XercesXMLBytePtr() .../src/msix/PAL/XML/xerces-c/XmlObject.cpp:215
9 │ #3 0x557eb4d48e1f in MSIX::XercesElement::GetBase64DecodedAttributeValue(XmlAttributeName) .../src/msix/PAL/XML/xerces-c/XmlObject.cpp:265
...
43 │ allocated by thread T0 here:
44 │ #0 0x557eb3c03907 in operator new(unsigned long) (test_executable+0x2df0907)
45 │ #1 0x557eb4e5dfd2 in xercesc_3_2::getExternalMemory(xercesc_3_2::MemoryManager*, unsigned long) (test_executable+0x404afd2)
46 │ #2 0x557eb4e5eba8 in xercesc_3_2::Base64::decode(unsigned char const*, unsigned long*, unsigned char*&, xercesc_3_2::MemoryManager*, xercesc_3_2::Base64::Conformance) (test_executable+0x404bba8)
47 │ #3 0x557eb4e5e581 in xercesc_3_2::Base64::decode(unsigned char const*, unsigned long*, xercesc_3_2::MemoryManager*, xercesc_3_2::Base64::Conformance) (test_executable+0x404b581)
48 │ #4 0x557eb4e5e6be in xercesc_3_2::Base64::decodeToXMLByte(char16_t const*, unsigned long*, xercesc_3_2::MemoryManager*, xercesc_3_2::Base64::Conformance) (test_executable+0x404b6be)
49 │ #5 0x557eb4d48c3b in MSIX::XercesElement::GetBase64DecodedAttributeValue(XmlAttributeName) .../src/msix/PAL/XML/xerces-c/XmlObject.cpp:265
...
SUMMARY: AddressSanitizer: new-delete-type-mismatch (test_executable+0x2df196f) in operator delete(void*, unsigned long)
77 │ ==23071==HINT: if you don't care about these errors you may set ASAN_OPTIONS=new_delete_type_mismatch=0
78 │ ==23071==ABORTING
To Reproduce
Let address sanitizer look at this code:
XercesXMLBytePtr decodedData(XERCES_CPP_NAMESPACE::Base64::decodeToXMLByte("dGVzdAo=", &len));Expected behavior
Address sanitizer does not complain. Correct new and delete are used to allocate and deallocate memory.
Screenshots
N/A
Platform
Linux
Additional context
This happens on Linux, where MSIX packaging is using Xerces-c as its XML backend.