You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating #1870, running outside of the chrome_tests script, content_unittests FileSystemDirURLRequestJobTest.DirectoryListing (and probably any other test) has this mismatch reported:
So v8::base::OS::DisposeTimezoneCache == operator delete[]. This is hard to solve, b/c here we have separate delete and delete[] and it looks at the surface like we can successfully detect mismatches. How can we possibly know that the compiler is going to place DisposeTimezoneCache where delete[] is instead of delete? In some sense it seems like a bug, though with no regular consequences.
This will not show up on Cr bots b/c we run with -no_check_delete_mismatch for Release build.
That was due to another related issue in v8: #1625.
For non-Cr DrMem: it is not clear what we can do other than suggest that heap mismatch only be enabled for non-VS-optimized builds or something.
This just adds more nails in the coffin of the whole delete vs delete[] mismatch detection feature with Visual Studio: the compiler's lack of concern for operator separation makes it impractical.
The text was updated successfully, but these errors were encountered:
derekbruening
changed the title
heap mismatch due to VS aliasing to delete[] a function that calls delete
heap mismatch due to VS2015 aliasing to delete[] a function that calls delete
Mar 20, 2016
While investigating #1870, running outside of the chrome_tests script, content_unittests FileSystemDirURLRequestJobTest.DirectoryListing (and probably any other test) has this mismatch reported:
Relevant source code:
Analysis:
So v8::base::OS::DisposeTimezoneCache == operator delete[]. This is hard to solve, b/c here we have separate delete and delete[] and it looks at the surface like we can successfully detect mismatches. How can we possibly know that the compiler is going to place DisposeTimezoneCache where delete[] is instead of delete? In some sense it seems like a bug, though with no regular consequences.
This will not show up on Cr bots b/c we run with -no_check_delete_mismatch for Release build.
That was due to another related issue in v8: #1625.
For non-Cr DrMem: it is not clear what we can do other than suggest that heap mismatch only be enabled for non-VS-optimized builds or something.
This just adds more nails in the coffin of the whole delete vs delete[] mismatch detection feature with Visual Studio: the compiler's lack of concern for operator separation makes it impractical.
The text was updated successfully, but these errors were encountered: