boost::pool memory question
Hi! I have tried this program: If I use valgrind obtain this output: It is normal? -- View this message in context: http://boost.2283326.n4.nabble.com/boost-pool-memory-question-tp4634559.html Sent from the Boost - Users mailing list archive at Nabble.com.
On Tue, Aug 21, 2012 at 07:46:32AM -0700, Claude wrote:
Hi! I have tried this program:
If I use valgrind obtain this output:
It is normal?
Your mail does not contain any relevant text. Also, valgrind has lots of spurious warnings, it's an artform to sift out the true problems from all the false positives it spews out. -- Lars Viklund | zao@acc.umu.se
Your mail does not contain any relevant text.
I do not understand what you tell me... -- View this message in context: http://boost.2283326.n4.nabble.com/boost-pool-memory-question-tp4634559p4634... Sent from the Boost - Users mailing list archive at Nabble.com.
On Tue, Aug 21, 2012 at 10:32 AM, Claude <clros@tiscali.it> wrote:
Your mail does not contain any relevant text.
I do not understand what you tell me...
In email, your valgrind output does not show up. Perhaps because it is not plain text? Everything shows up fine in the web thread. FWIW, assuming release_memory() should call delete[] on the pool's internal memory buffers, this does indeed seem like a leak. Moreover, it appears that delete[] is never called, even at pool destruction. Valgrind actually rarely spews spurious errors. Sometimes they don't matter (invalid reads/writes for memcpy on structures with padding, etc...), but it's pretty much always spot-on. Brian
In email, your valgrind output does not show up. Perhaps because it is not plain text? Everything shows up fine in the web thread.
Opss, excuse me! This is the simple program: #include <iostream> #include <vector> #include <boost/pool/pool_alloc.hpp> using namespace std; int main() { std::vector<int,boost::pool_allocator<int>> myVector; for (int64_t i = 0; i < 150000; ++i) myVector.push_back(13); boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory(); return 0; } and this is the valgring output: ==2612== HEAP SUMMARY: ==2612== in use at exit: 4,194,296 bytes in 15 blocks ==2612== total heap usage: 15 allocs, 0 frees, 4,194,296 bytes allocated ==2612== ==2612== 4,194,296 bytes in 15 blocks are still reachable in loss record 1 of 1 ==2612== at 0x402B031: operator new[](unsigned int, std::nothrow_t const&) (vg_replace_malloc.c:372) ==2612== by 0x804A0F8: ??? (in /home/claudio-ubuntu/Scrivania/ProvaPool/bin/Release/ProvaPool) ==2612== by 0x804A4E4: ??? (in /home/claudio-ubuntu/Scrivania/ProvaPool/bin/Release/ProvaPool) ==2612== by 0x8048C03: ??? (in /home/claudio-ubuntu/Scrivania/ProvaPool/bin/Release/ProvaPool) ==2612== by 0x41684D2: (below main) (libc-start.c:226) ==2612== ==2612== LEAK SUMMARY: ==2612== definitely lost: 0 bytes in 0 blocks ==2612== indirectly lost: 0 bytes in 0 blocks ==2612== possibly lost: 0 bytes in 0 blocks ==2612== still reachable: 4,194,296 bytes in 15 blocks ==2612== suppressed: 0 bytes in 0 blocks -- View this message in context: http://boost.2283326.n4.nabble.com/boost-pool-memory-question-tp4634559p4634... Sent from the Boost - Users mailing list archive at Nabble.com.
On Tue, 21 Aug 2012 22:55:27 +0200, Claude <clros@tiscali.it> wrote:
In email, your valgrind output does not show up. Perhaps because it is not plain text? Everything shows up fine in the web thread.
Opss, excuse me!
This is the simple program:
#include <iostream> #include <vector> #include <boost/pool/pool_alloc.hpp>
using namespace std;
int main() { std::vector<int,boost::pool_allocator<int>> myVector;
for (int64_t i = 0; i < 150000; ++i) myVector.push_back(13);
boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory(); return 0; }
and this is the valgring output:
Not sure what you are wondering about. But maybe this note from <http://www.boost.org/doc/libs/1_51_0/libs/pool/doc/html/boost/singleton_pool.html> helps: The underlying pool constructed by the singleton is never freed. This means that memory allocated by a singleton_pool can be still used after main() has completed, but may mean that some memory checking programs will complain about leaks from singleton_pool. Boris
[...]
participants (4)
-
Boris Schaeling -
Brian Budge -
Claude -
Lars Viklund