detect mismatched use of malloc/new/new[] vs free/delete/delete[] #123
Comments
|
From bruen...@google.com on October 20, 2011 10:01:43 in my small tests, /O2 leaves the operator delete* in place with their tailcalls, so I have yet to see them optimized away: we'll wait and see whether we see any false positive mismatch errors reported in the field I guess. note that this is much less likely on linux where static libstdc++ is rare. note that adding new and delete as a first-class heap layer can mask unaddr errors in custom operators. should still catch non-heap accesses (in slowpath) but this will allow operator new and delete to touch any heap header: but since new[] and new note that the new[] size field is NOT marked unaddressable even with new[] its own heap layer, b/c the caller is the one who asks for extra size and stores the size. we could try to mark the size unaddressable (maybe shift the malloc start too, which would be an alternative to -midchunk_new_ok) but then we have to recognize the code patterns that store it and read it: not worth the effort IMHO. |
|
From bruen...@google.com on October 20, 2011 18:52:34 an issue with /MD (xref issue #637 ) if don't have symbols: asymmetric inlines! still goes through cs2bug!operator new[] and cs2bug!operator new and then 0:001> U 00402576 0:001> U 00402606 this is not just an app issue, where can make it a usage error: could have Error 0 MSVCP80.dll!std::numpunct<wchar_t>::_Tidy1 MSVCP80.dll!std::numpunct::~numpunct2 MSVCP80.dll!std::tan3 MSVCP80.dll!std::_Lockit::_Lockit_dtor4 MSVCP80.dll!std::locale::_Locimp::_Locimp_dtor5 MSVCP80.dll!LDunscale6 MSVCP80.dll!LDunscale7 MSVCP80.dll!LDunscale8 ntdll.dll!LdrShutdownProcess9 KERNEL32.dll!_ExitProcess#10 KERNEL32.dll!ExitProcess Error 0 MSVCP80.dll!std::numpunct<wchar_t>::_Tidy1 MSVCP80.dll!std::numpunct::~numpunct2 MSVCP80.dll!std::tan3 MSVCP80.dll!std::_Lockit::_Lockit_dtor4 MSVCP80.dll!std::locale::_Locimp::_Locimp_dtor5 MSVCP80.dll!LDunscale6 MSVCP80.dll!LDunscale7 MSVCP80.dll!LDunscale8 ntdll.dll!LdrShutdownProcess9 KERNEL32.dll!_ExitProcess#10 KERNEL32.dll!ExitProcess Error 0 MSVCP80.dll!std::numpunct<wchar_t>::_Tidy1 MSVCP80.dll!std::numpunct::~numpunct2 MSVCP80.dll!std::tan3 MSVCP80.dll!std::_Lockit::_Lockit_dtor4 MSVCP80.dll!std::locale::_Locimp::_Locimp_dtor5 MSVCP80.dll!LDunscale6 MSVCP80.dll!LDunscale7 MSVCP80.dll!LDunscale8 ntdll.dll!LdrShutdownProcess9 KERNEL32.dll!_ExitProcess#10 KERNEL32.dll!ExitProcess on win7 laptop where I can get symbols for easier analysis (getting the 0 MSVCP90.dll!std::numpunct::_Tidy+0xc (0x7038dcb0 <MSVCP90.dll+0xdcb0>)1 MSVCP90.dll!std::_Lockit::_Lockit_dtor+0x54 (0x703b5bda <MSVCP90.dll+0x35bda>)2 MSVCP90.dll!std::locale::_Locimp::_Locimp_dtor+0x87 (0x703b5d6c <MSVCP90.dll+0x35d6c>)Note: @0:00:00.996 in thread 6176 0:000> U 0x7038dcb0-5 0:000> U 0x7038fed9 -5 solution?: need to look at caller and only report when have symbols caller-syms solution: but you could imagine code compiled by some other simpler idea: don't check caller for syms. instead, assume anyone calling risk is if any compiler setting, or other compiler, directly calls msvcr*: Owner: bruen...@google.com |
|
From bruen...@google.com on October 21, 2011 11:52:44 another big problem: placement new. even if identify it via arg examination, "placement delete" can vary quite a bit. better solution: make these operators all be non-adjusting heap layers, only used to check for mismatches. then they don't care whether placement new or not, or what the |
|
From derek.br...@gmail.com on October 22, 2011 22:20:55 This issue was closed by revision r564 . Status: Fixed |
|
From timurrrr@google.com on October 26, 2011 07:00:25 Usability is not very good, see issue #644 |
|
From timurrrr@google.com on October 26, 2011 07:01:03 Issue 54 has been merged into this issue. |
|
From bruen...@google.com on October 26, 2011 07:08:43
|
From derek.br...@gmail.com on December 10, 2010 17:57:49
PR 408581
This is not simply a leak issue, which is why it has to be treated
specially: this is an issue of whether or not destructors are called.
Xref the
scalar deleting destructor' andvector deleting destructor' usedby the Windows libc.
Note that for objects with no destructor if the code is optimized there may
be no way to distinguish between delete[] and free (no error either to
mismatch but would still be nice to report in case destructor is later
added).
We may want to mark the new[] special header as unaddressable as long as we're
distinguishing new[] from other routes to malloc()
Original issue: http://code.google.com/p/drmemory/issues/detail?id=123
The text was updated successfully, but these errors were encountered: