2

I am running a code and I encounter the error as

* glibc detected * /home/build/bin/../bin/OPENSUSE_12.2_X86_64/reader: corrupted double-linked list: 0x0000000003df6dc0 *

I tried to re-run it by valgrind to know whether if any memory leak is the problem. I run it as

valgrind --leak-check=full -v ./myprog

since the program does not complete and stops the valgrind summary is as below:

>     ==5335== Process terminating with default action of signal 2 (SIGINT)
>     ==5335==    at 0x54E4007: kill (in /lib64/libc-2.15.so)
>     ==5335==    by 0x429473: ??? (in /bin/bash)
>     ==5335==    by 0x42A313: wait_for (in /bin/bash)
>     ==5335==    by 0x462BFE: execute_command_internal (in /bin/bash)
>     ==5335==    by 0x463360: execute_command (in /bin/bash)
>     ==5335==    by 0x41B7F0: reader_loop (in /bin/bash)
>     ==5335==    by 0x41B4C9: main (in /bin/bash)
>     ==5335== 
>     ==5335== HEAP SUMMARY:
>     ==5335==     in use at exit: 37,513 bytes in 1,074 blocks
>     ==5335==   total heap usage: 1,922 allocs, 848 frees, 72,605 bytes allocated
>     ==5335== 
>     ==5335== Searching for pointers to 1,074 not-freed blocks
>     ==5335== Checked 220,224 bytes
>     ==5335== 
>     ==5335== LEAK SUMMARY:
>     ==5335==    definitely lost: 0 bytes in 0 blocks
>     ==5335==    indirectly lost: 0 bytes in 0 blocks
>     ==5335==      possibly lost: 0 bytes in 0 blocks
>     ==5335==    still reachable: 37,513 bytes in 1,074 blocks
>     ==5335==         suppressed: 0 bytes in 0 blocks
>     ==5335== Reachable blocks (those to which a pointer was found) are not shown.
>     ==5335== To see them, rerun with: --leak-check=full --show-reachable=yes
>     ==5335== 
>     ==5335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
>     --5335-- 
>     --5335-- used_suppression:      2 dl-hack3-cond-1
>     ==5335== 
>     ==5335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

in the total heap usage: 1,922 allocs, 848 frees and I wonder if here might be any problem? but in error summary there is no error. I wonder if I should be concerned about any problem in the code or memory leak?

user3619806
  • 31
  • 1
  • 1
  • 6
  • it's very hard to analyse if you program is correctly releasing its memory when you kill it with a signal, try ending it naturally (by reaching main's return). – Drax Aug 13 '14 at 12:56
  • The quoted trace is for `/bin/bash`, not for `myprog`, so I don't think you're running valgrind on what you think you're running it on. Unless `myprog` is a bash script? – Chris Dodd Aug 02 '23 at 22:26
  • compile with -fsantize=undefined instead of using valgrind – pm100 Aug 02 '23 at 23:02

2 Answers2

1

The original error message you have (from glibc) is from it detecting heap coprruption -- someone is running off the end of a buffer or is otherwise writing through an undefined pointer and causing the heap's internal data structures to be corrupted. This is unrelated to any memory leak, but valgrind may also be useful in tracking it down -- if you run your actual program with valgrind (not a shell script) then you should get messages about "invalid writes" showing where the heap corruption is actually happening.

Your posted valgrind trace indicates that it is from /bin/bash and not myprog. Your posted glibc error indicates that it is coming from a program called reader (again, not myprog)

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
0

This summary basically means that you didn't discard any pointers (set them to NULL) without first freeing associated allocated memory. When the program exits, any allocated memory (whether leaked or not) will be freed regardless. However, you are correct - you are not leaking any memory, so if your program runs for an extended period of time, you won't run out of heap space.

Ideally though, you should still try to clean up after yourself - look for malloc calls, without any corresponding free calls.

roelofs
  • 2,132
  • 20
  • 25
  • If you're using arrays, they can be indicated as allocated memory (an array variable is really just a pointer). – roelofs Aug 13 '14 at 09:48