2

The following code 

#include <deque>
int main() {
  std::deque<int> Q;
  return 0;
}

produces a non-clean exit as per valgrind:

==9942== HEAP SUMMARY:
==9942==     in use at exit: 72,704 bytes in 1 blocks
==9942==   total heap usage: 3 allocs, 2 frees, 73,280 bytes allocated
==9942== 
==9942== LEAK SUMMARY:
==9942==    definitely lost: 0 bytes in 0 blocks
==9942==    indirectly lost: 0 bytes in 0 blocks
==9942==      possibly lost: 0 bytes in 0 blocks
==9942==    still reachable: 72,704 bytes in 1 blocks
==9942==         suppressed: 0 bytes in 0 blocks

Code compiled with g++ on Linux Mint.

Is this a bug in the standard library?

Is there any way to get a clean exit?

Changing to a "new/delete" methodology just reports 4 allocs and 3 frees...

Rama
  • 3,222
  • 2
  • 11
  • 26
Dr. Wolfe
  • 121
  • 1
  • 6
  • 3
    You're probably seeing stuff that was allocated by the runtime. If `deque` leaked there would be a lot of broken code out there. – NathanOliver Jan 27 '17 at 17:02
  • It could be an optimization. The implementer of the standard library knows that the system uses virtual memory, so it speeds up process termination by leaking the memory on purpose. Just a guess, though. – eerorika Jan 27 '17 at 17:02
  • 1
    I somehow doubt an empty deque would take 72 704 bytes of memory. Are you sure the deque is responsible for that allocation? – Frédéric Hamidi Jan 27 '17 at 17:03
  • Can't reproduce. What do you see without deque? – Marc Glisse Jan 27 '17 at 17:03
  • "definitely lost: 0 bytes" <-- it's only a "real" memory leak if this one is non-zero. I think you're fine. – Jeremy Friesner Jan 27 '17 at 22:39
  • This is definitely an issue with my particular linux box. I've tried it on several other computers and valgrind reports completely clean with only 128bytes used (as opposed to >70KB). I downloaded and compiled gcc v5.4 with minimal options and am still having the same issue. If I figure it out I'll post back. – Dr. Wolfe Jan 31 '17 at 18:18

0 Answers0