|
From: Niall D. <ndo...@bl...> - 2013-06-04 18:22:39
Attachments:
smime.p7s
|
Dear valgrind devs, I have some C++ implementing a static type registry where you really, really must fire and forget some memory allocations because it's potentially segfault causing if you try cleaning up. This happens because until we get C++ Modules, we can't know the order of deinit of statically allocated objects. Also, on ELF newly loaded shared objects may overwrite what storage an extern variable refers to, and a fire and forget can be used to work around the problem. Is there some sort of magic macro e.g. VALGRIND_IGNORE_LEAKED_BLOCK(ptr) or even better: VALGRIND_BEGIN_IGNORE_MEM_LEAKS(); ... VALGRIND_END_IGNORE_MEM_LEAKS(); I say this is better because my C++ fire and forgets a std::unordered_map<size_t, std::map<std::string, void *>> which obviously implies more than one malloc by the STL. If even there were some way of abusing some other valgrind macro instrumentation to achieve the same effect, I'm good. This is the only problem case in the entire code base. It's quite literally five lines of code, so is very tightly contained. Thanks, Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc. |
|
From: Philippe W. <phi...@sk...> - 2013-06-04 18:44:01
|
On Tue, 2013-06-04 at 18:22 +0000, Niall Douglas wrote: > Is there some sort of magic macro e.g. VALGRIND_IGNORE_LEAKED_BLOCK(ptr) or > even better: > > VALGRIND_BEGIN_IGNORE_MEM_LEAKS(); > ... > VALGRIND_END_IGNORE_MEM_LEAKS(); No there is no such macros. > > I say this is better because my C++ fire and forgets a > std::unordered_map<size_t, std::map<std::string, void *>> which obviously > implies more than one malloc by the STL. > > If even there were some way of abusing some other valgrind macro > instrumentation to achieve the same effect, I'm good. This is the only > problem case in the entire code base. It's quite literally five lines of > code, so is very tightly contained. Is there a reason why suppression entries cannot be used to suppress this leak report ? Philippe |
|
From: Niall D. <ndo...@bl...> - 2013-06-04 19:12:14
Attachments:
smime.p7s
|
> > If even there were some way of abusing some other valgrind macro > > instrumentation to achieve the same effect, I'm good. This is the only > > problem case in the entire code base. It's quite literally five lines > > of code, so is very tightly contained. > Is there a reason why suppression entries cannot be used to suppress this > leak > report ? Generally when a behavior is an intentional, deliberate part of a code base it's better to add valgrind macros so later developers can see what you're doing and understand why. They then don't try things like fixing memory leaks which are deliberate and intentional due to cross-platform portability requirements. I think for now the best course is if running under valgrind, do an ELF-specific cleanup to make valgrind clean. Thanks for the help. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc. |
|
From: Philippe W. <phi...@sk...> - 2013-06-04 19:33:50
|
On Tue, 2013-06-04 at 19:12 +0000, Niall Douglas wrote: > Generally when a behavior is an intentional, deliberate part of a code base > it's better to add valgrind macros so later developers can see what you're > doing and understand why. They then don't try things like fixing memory leaks > which are deliberate and intentional due to cross-platform portability > requirements. It looks to me that a suppression file entry can clearly describe which leak(s) to suppress and can contain a comment that explain why you are suppressing it. (of course, you can also add a comment in the code, telling that the intentional leak at that line is suppressed in a valgrind suppression file). Note that I think the macro you suggested would not be very difficult to implement, but it is not clear to me that they bring something which cannot be done with suppression files. Philippe |