Custom memory allocators break tools

[GoogleCodeExporter]

nvcore/Memory.h overrides the global operator new and operator delete. In 2.0, 
Memory.cpp implements these in terms of malloc/free. In trunk, it uses 
malloc/free unless you modify the source code to enable USE_EFENCE.

This breaks some features in tools like Valgrind, whenever an application links 
against nvtt: it is designed to detect mismatched allocation calls ("free(new 
int)", "delete(malloc(n))", etc) but it can't recognise them when everything is 
implemented as malloc/free.

Since Memory.h doesn't override the std::nothrow allocation functions, it will 
also introduce bugs into an otherwise-valid program that allocates with 
std::nothrow and deletes without (since the delete will use free(), which is 
mismatched with the 'new').

It also makes new/delete a (very) tiny bit slower, by adding an extra 
dynamic-library call.

Since this overloading doesn't seem to achieve anything generally useful (as 
far as I'm aware), it should probably just be removed. If the efence feature is 
useful then Memory.h should enable the overrides only if USE_EFENCE was 
enabled, so that the compatibility/performance cost only affects developers who 
want that feature.

Original issue reported on code.google.com by exc...@gmail.com on 29 Sep 2010 at 1:54

[GoogleCodeExporter]

Yeah, I think you are right.

Ideally what I'd like to achieve is to have all the memory allocated by NVTT go 
through the same allocator, a common request is to provide hooks for custom 
memory allocation functions, see issue 106. This was there only to accomodate 
requests like that in the future.

However, it seems that the overrides are affecting the whole program, not just 
NVTT. I need to figure out how to solve that, but in the meantime disabling 
this is probably the best way to go.

Original comment by cast...@gmail.com on 29 Sep 2010 at 5:20

• Changed state: Accepted

[GoogleCodeExporter]

Here's something interesting that may explain the behavior you are seeing:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404

Recent C++ standards disallow the use of inline in the declaration of new and 
delete. While that's supposed to be an error, I suspect gcc is silently 
allowing it, but not treating the functions as inline. Instead it's exporting 
the symbols and replacing them for the whole program, which was not the 
intended behavior.

Anyway, I clearly need to comment that out. I'll figure out the solution 
another time.

Original comment by cast...@gmail.com on 1 Oct 2010 at 6:02

[GoogleCodeExporter]

I've fixed this in trunk. Will merge the changes to the 2.0 branch shortly.

Original comment by cast...@gmail.com on 6 Oct 2010 at 3:03

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r1172.

Original comment by cast...@gmail.com on 28 Oct 2010 at 4:25

• Changed state: Fixed