1

I've looked around various bug notes and stackoverflow questions on this matter (link here) but I am still unable to understand whether:
is it possible to write my c++ code in such a fashion that it will release the problematic block's memory?

valgrind faq states that:

Using GCC, you can force the STL to use malloc and to free memory as soon as possible by globally disabling memory caching. Beware! Doing so will probably slow down your program, sometimes drastically.

With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using the STL with -D__USE_MALLOC. Beware! This was removed from GCC starting with version 3.3.

With GCC 3.2.2 and later, you should export the environment variable GLIBCPP_FORCE_NEW before running your program.

With GCC 3.4 and later, that variable has changed name to GLIBCXX_FORCE_NEW.

I'm using c9.io as a c++ workbench for my academic assignments and compiling using:
g++ -Wall -Wvla -Werror -g -D_GLIBCXX_DEBUG -std=c++11

c9's gcc version is: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)

Sadly though I'm at a loss when it comes to understanding the suggested tweak. how do I add this to my project?
if this isn't the only possible solution, is there any other?

Full valgrind output:

Press [Enter] key to start memory check of test executable...
valgrind --leak-check=full --show-leak-kinds=all -v ./MyLinkedListTest
==4729== Memcheck, a memory error detector
==4729== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4729== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==4729== Command: ./MyLinkedListTest
==4729== 
--4729-- Valgrind options:
--4729--    --leak-check=full
--4729--    --show-leak-kinds=all
--4729--    -v
--4729-- Contents of /proc/version:
--4729--   Linux version 4.2.0-c9 (root@11aafb97cfeb) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Fri Nov 20 14:49:01 UTC 2015
--4729-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--4729-- Page sizes: currently 4096, max supported 4096
--4729-- Valgrind library directory: /usr/lib/valgrind
--4729-- Reading syms from /home/ubuntu/workspace/MyLinkedListTest
--4729-- Reading syms from /lib/x86_64-linux-gnu/ld-2.19.so
--4729--   Considering /lib/x86_64-linux-gnu/ld-2.19.so ..
--4729--   .. CRC mismatch (computed ef2bc4a1 wanted 12987a55)
--4729--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ..
--4729--   .. CRC is valid
--4729-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--4729--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--4729--   .. CRC mismatch (computed 4f1eed43 wanted a323a3ab)
--4729--    object doesn't have a symbol table
--4729--    object doesn't have a dynamic symbol table
--4729-- Scheduler: using generic scheduler lock implementation.
--4729-- Reading suppressions file: /usr/lib/valgrind/default.supp
==4729== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-4729-by-ubuntu-on-???
==4729== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-4729-by-ubuntu-on-???
==4729== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-4729-by-ubuntu-on-???
==4729== 
==4729== TO CONTROL THIS PROCESS USING vgdb (which you probably
==4729== don't want to do, unless you know exactly what you're doing,
==4729== or are doing some strange experiment):
==4729==   /usr/lib/valgrind/../../bin/vgdb --pid=4729 ...command...
==4729== 
==4729== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==4729==   /path/to/gdb ./MyLinkedListTest
==4729== and then give GDB the following command
==4729==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=4729
==4729== --pid is optional if only one valgrind process is running
==4729== 
--4729-- REDIR: 0x4019ca0 (ld-linux-x86-64.so.2:strlen) redirected to 0x380764b1 (???)
--4729-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--4729--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--4729--   .. CRC mismatch (computed fc68135e wanted 45f5e986)
--4729--    object doesn't have a symbol table
--4729-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--4729--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--4729--   .. CRC mismatch (computed ae683f7e wanted 08c06df2)
--4729--    object doesn't have a symbol table
==4729== WARNING: new redirection conflicts with existing -- ignoring it
--4729--     old: 0x04019ca0 (strlen              ) R-> (0000.0) 0x380764b1 ???
--4729--     new: 0x04019ca0 (strlen              ) R-> (2007.0) 0x04c2e1a0 strlen
--4729-- REDIR: 0x4019a50 (ld-linux-x86-64.so.2:index) redirected to 0x4c2dd50 (index)
--4729-- REDIR: 0x4019c70 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2f2f0 (strcmp)
--4729-- REDIR: 0x401a9c0 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c31da0 (mempcpy)
--4729-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
--4729--   Considering /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 ..
--4729--   .. CRC mismatch (computed bb97d222 wanted 173a3577)
--4729--    object doesn't have a symbol table
--4729-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--4729--   Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--4729--   .. CRC mismatch (computed f2c4ceb3 wanted bf2e028d)
--4729--    object doesn't have a symbol table
--4729-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.19.so
--4729--   Considering /lib/x86_64-linux-gnu/libpthread-2.19.so ..
--4729--   .. CRC mismatch (computed 4841b2fb wanted eec353ab)
--4729--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.19.so ..
--4729--   .. CRC is valid
--4729-- Reading syms from /lib/x86_64-linux-gnu/libc-2.19.so
--4729--   Considering /lib/x86_64-linux-gnu/libc-2.19.so ..
--4729--   .. CRC mismatch (computed 600bae51 wanted b4d0580d)
--4729--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so ..
--4729--   .. CRC is valid
--4729-- Reading syms from /lib/x86_64-linux-gnu/libm-2.19.so
--4729--   Considering /lib/x86_64-linux-gnu/libm-2.19.so ..
--4729--   .. CRC mismatch (computed 0fbb5cf0 wanted cac31e3b)
--4729--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.19.so ..
--4729--   .. CRC is valid
--4729-- REDIR: 0x5605d60 (libc.so.6:strcasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--4729-- REDIR: 0x5608050 (libc.so.6:strncasecmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--4729-- REDIR: 0x5605530 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--4729-- REDIR: 0x56037c0 (libc.so.6:rindex) redirected to 0x4c2da30 (rindex)
--4729-- REDIR: 0x55fb750 (libc.so.6:malloc) redirected to 0x4c2ab10 (malloc)
--4729-- REDIR: 0x5601ac0 (libc.so.6:strlen) redirected to 0x4c2e0e0 (strlen)
--4729-- REDIR: 0x5604fa0 (libc.so.6:__GI_memcmp) redirected to 0x4c30b80 (__GI_memcmp)
--4729-- REDIR: 0x5600070 (libc.so.6:strcmp) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--4729-- REDIR: 0x56b9200 (libc.so.6:__strcmp_ssse3) redirected to 0x4c2f1b0 (strcmp)
--4729-- REDIR: 0x4e9ee50 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4c2b070 (operator new(unsigned long))
--4729-- REDIR: 0x560a730 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--4729-- REDIR: 0x5610fd0 (libc.so.6:__memcpy_sse2_unaligned) redirected to 0x4c2f6b0 (memcpy@@GLIBC_2.14)
--4729-- REDIR: 0x4e9ef00 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2b790 (operator new[](unsigned long))
--4729-- REDIR: 0x56055c0 (libc.so.6:memset) redirected to 0x4c31350 (memset)
--4729-- REDIR: 0x4e9d0a0 (libstdc++.so.6:operator delete[](void*)) redirected to 0x4c2c7d0 (operator delete[](void*))
--4729-- REDIR: 0x55ffe20 (libc.so.6:index) redirected to 0x4a25720 (_vgnU_ifunc_wrapper)
--4729-- REDIR: 0x55ffe50 (libc.so.6:__GI_strchr) redirected to 0x4c2db90 (__GI_strchr)
--4729-- REDIR: 0x56c9090 (libc.so.6:__memmove_ssse3_back) redirected to 0x4c2f450 (memcpy@GLIBC_2.2.5)
--4729-- REDIR: 0x4e9d070 (libstdc++.so.6:operator delete(void*)) redirected to 0x4c2c250 (operator delete(void*))
--4729-- REDIR: 0x55fbdf0 (libc.so.6:free) redirected to 0x4c2bd80 (free)
==4729== 
==4729== HEAP SUMMARY:
==4729==     in use at exit: 72,704 bytes in 1 blocks
==4729==   total heap usage: 260 allocs, 259 frees, 122,246 bytes allocated
==4729== 
==4729== Searching for pointers to 1 not-freed blocks
==4729== Checked 139,240 bytes
==4729== 
==4729== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==4729==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4729==    by 0x4E9B2AF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4729==    by 0x4010139: call_init.part.0 (dl-init.c:78)
==4729==    by 0x4010222: call_init (dl-init.c:36)
==4729==    by 0x4010222: _dl_init (dl-init.c:126)
==4729==    by 0x4001309: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==4729== 
==4729== LEAK SUMMARY:
==4729==    definitely lost: 0 bytes in 0 blocks
==4729==    indirectly lost: 0 bytes in 0 blocks
==4729==      possibly lost: 0 bytes in 0 blocks
==4729==    still reachable: 72,704 bytes in 1 blocks
==4729==         suppressed: 0 bytes in 0 blocks
==4729== 
==4729== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==4729== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Community
  • 1
  • 1
HazirBot
  • 323
  • 2
  • 14
  • Valgrind is usually very good at finding the source of the memory leaks, it doesn't say anything else that could be useful to know? – Some programmer dude Apr 18 '16 at 14:23
  • @JoachimPileborg im experiencing the same stack trace that's been posted at the linked question. would it be more clarified were i to re-post this here? – HazirBot Apr 18 '16 at 14:25
  • What about rebuilding `libstdc++` with debug info and rerun your test again? – fghj Apr 18 '16 at 15:49
  • @user1034749 how do i that? is that possible when working on `c9.io`? – HazirBot Apr 18 '16 at 16:33
  • With `c9.io` you need talk with its support, on normal `PC` with `Ubuntu` you need just install corresponding `-dbg` packet. – fghj Apr 18 '16 at 16:38
  • @user1034749 suppose i go through with that, will that allow me into a deeper understanding of "why" the block gets assigned, or towards "how" to release it? – HazirBot Apr 18 '16 at 16:42
  • Look at your backtrace, obviously the culprit inside `libstdc++` – fghj Apr 18 '16 at 16:59
  • @user1034749 suppose i find the error in `libstdc++` and understand how to fix it, will that lead me to a solution that i can implement in my own project so that it'll work on other machines? there are already patches for this problem that require recompiling gcc on my machine. But those will only work on my end. – HazirBot Apr 18 '16 at 17:06
  • I suppose the right solution after you fix problem, will be suppress this error in `valgrind`, because of memory link once at start is harmless – fghj Apr 18 '16 at 17:10
  • @user1034749 how can i do that? – HazirBot Apr 18 '16 at 17:23

0 Answers0