Boost C++ Libraries: Ticket #3976: [pool] Modifications to allow Boost.Pool uses to be checked by Valgrind

attachment set

Jeremiah Willcock — Wed, 03 Mar 2010 18:01:04 GMT

attachment → pool_valgrind.patch

Patch for Valgrind support

attachment set

Jeremiah Willcock — Wed, 03 Mar 2010 18:33:29 GMT

attachment → pool_valgrind_2.patch

Version of patch that removes spurious Valgrind errors in pool internals

attachment set

Jeremiah Willcock — Wed, 03 Mar 2010 18:34:39 GMT

attachment → bogus_pool_test.cpp

Test code (run under Valgrind with modified pool)

attachment set

Jeremiah Willcock — Wed, 03 Mar 2010 19:54:37 GMT

attachment → pool_valgrind_3.patch

Removed more warnings in pool internals

Steven Watanabe — Thu, 10 Jun 2010 01:40:15 GMT

Is the use of VALGRIND a convention? Otherwise, I would much prefer using BOOST_POOL_VALGRIND.

cc set

John Maddock — Fri, 07 Jan 2011 11:24:37 GMT

cc boostpool@… added

status changed; resolution set

John Maddock — Thu, 03 Mar 2011 18:25:23 GMT

status new → closed
resolution → wontfix

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".

edupuis — Fri, 04 May 2012 20:51:58 GMT

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

anonymous — Sat, 05 May 2012 08:47:27 GMT

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?