#3976 closed Patches (wontfix)
[pool] Modifications to allow Boost.Pool uses to be checked by Valgrind
| Reported by: | Jeremiah Willcock | Owned by: | Chris Newbold |
|---|---|---|---|
| Milestone: | Boost 1.43.0 | Component: | pool |
| Version: | Boost Development Trunk | Severity: | Not Applicable |
| Keywords: | Cc: | boostpool@… |
Description
The attached patch uses Valgrind client requests to mark chunks allocated and freed from Boost.Pool pools correctly, plus to mark unallocated space in a pool as non-accessible. The patched code requires the preprocessor symbol VALGRIND to be defined to add the extra requests.
Attachments (4)
Change History (9)
by , 13 years ago
| Attachment: | pool_valgrind.patch added |
|---|
by , 13 years ago
| Attachment: | pool_valgrind_2.patch added |
|---|
Version of patch that removes spurious Valgrind errors in pool internals
by , 13 years ago
| Attachment: | bogus_pool_test.cpp added |
|---|
Test code (run under Valgrind with modified pool)
comment:1 by , 12 years ago
Is the use of VALGRIND a convention? Otherwise, I would much prefer using BOOST_POOL_VALGRIND.
comment:2 by , 12 years ago
| Cc: | added |
|---|
comment:3 by , 12 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I've played around with this, but:
1) This results in a blizzard of warnings from valgrind (still). 2) The code is way too slow to be useful with valgrind integration enabled (some of our tests take "forever" to run in that case. 3) Unless I'm missing something, some of the warning suppressions result in functions being called twice, even when no Valgrind integration is enabled.
So... I'm closing as "won't fix".
comment:4 by , 10 years ago
John,
On July 18 2011, revision 73210, was commited with following log message : "Merge updated Boost.Pool from sandbox.". It added a second implementation of boost::pool, guarded by
#ifdef BOOST_POOL_VALGRIND #endif
This second implementation does not have at all the same behavior than the main one; if I understand correctly this implementation was the "playing around" mentionned above.
As I am currently fixing tickets related to Boost.Pool, I was wondering if I can delete this code which seems useless.
Regards
comment:5 by , 10 years ago
I'm not sure it's useless - if you want to test your code under valgrind then you have to do *something* to stop the blizzard of messages that would otherwise result - that was the best I could come up with at the time - it's tested in the Jamfile as well, but apparently I forgot to document it :-(
It does disable pooling, but the alternative (using the valgrind API's to mark up the blocks) is so incredibly slow as to be completely useless. So if you have a better idea then great.... but I think it needs something like this?
Patch for Valgrind support