We run our program on a Linux virtual machine which compiles from linux-2.6.3-long-term. I want to run valgrind on that machine, and I compile from source code in the suggested way.
./configure --prefix=/tmp/valgrind/
make
make install
Then, I copy the /tmp/valgrind to my own Linux machine, I put it on the directory /data, set the environment variables:
export PATH=$PATH:/data/valgrind/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib:/lib64:/data/valgrind/lib
export VALGRIND_LIB=/data/valgrind/lib/valgrind
The valgrind can work, and can detect some other errors except memory leak. Here is the result of running valgrind ls -l
==2207==
==2207== Conditional jump or move depends on uninitialised value(s)
==2207== at 0x80F3CDE: ??? (in /bin/busybox)
==2207== by 0x80548ED: ??? (in /bin/busybox)
==2207==
==2207== Use of uninitialised value of size 4
==2207== at 0x80D8F77: ??? (in /bin/busybox)
==2207== by 0x8048866: ??? (in /bin/busybox)
==2207==
==2207== Conditional jump or move depends on uninitialised value(s)
==2207== at 0x80F0F55: ??? (in /bin/busybox)
==2207== by 0x80D8F49: ??? (in /bin/busybox)
==2207== by 0x8048866: ??? (in /bin/busybox)
==2207==
==2207== Conditional jump or move depends on uninitialised value(s)
==2207== at 0x80F1000: ??? (in /bin/busybox)
==2207== by 0x80D8F49: ??? (in /bin/busybox)
==2207== by 0x8048866: ??? (in /bin/busybox)
==2207==
==2207==
==2207== HEAP SUMMARY:
==2207== in use at exit: 0 bytes in 0 blocks
==2207== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2207==
==2207== All heap blocks were freed -- no leaks are possible
==2207==
==2207== For counts of detected and suppressed errors, rerun with: -v
==2207== Use --track-origins=yes to see where uninitialised values come from
==2207== ERROR SUMMARY: 2390 errors from 117 contexts (suppressed: 0 from 0)
The total heap usage is all zero. And I find someone has already meet the same problem:
cross-compiled Valgrind does not detect obvious leaks
Is it a known issue?
The link above did not tell how to fix it, anyone know?
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
I'm new using Valgrind for the first time to check memory errrors. I'm running C program and seeing the errors that are not related to the C program but all the errors are from memory (open64.c:48, _IO_file_open (fileops.c:189), .....). I don't know where these files are located. Could you please help me how to resolve this?
==40910== Memcheck, a memory error detector
==40910== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==40910== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==40910== Command: ./dd
==40910==
==40910== Syscall param openat(filename) points to unaddressable byte(s)
==40910== at 0x4ABCEAB: open (open64.c:48)
==40910== by 0x4A3F195: _IO_file_open (fileops.c:189)
==40910== by 0x4A3F459: _IO_file_fopen##GLIBC_2.2.5 (fileops.c:281)
==40910== by 0x4A31B0D: __fopen_internal (iofopen.c:75)
==40910== by 0x4A31B0D: fopen##GLIBC_2.2.5 (iofopen.c:86)
==40910== by 0x109336: main (in /home/Desktop/dd)
==40910== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==40910==
==40910== Invalid read of size 4
==40910== at 0x4A317D7: fgets (iofgets.c:47)
==40910== by 0x109427: main (in /home/Desktop/dd)
==40910== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==40910==
==40910==
==40910== Process terminating with default action of signal 11 (SIGSEGV)
==40910== Access not within mapped region at address 0x0
==40910== at 0x4A317D7: fgets (iofgets.c:47)
==40910== by 0x109427: main (in /home/Desktop/dd)
==40910== If you believe this happened as a result of a stack
==40910== overflow in your program's main thread (unlikely but
==40910== possible), you can try to increase the size of the
==40910== main thread stack using the --main-stacksize= flag.
==40910== The main thread stack size used in this run was 16777216.
==40910==
==40910== HEAP SUMMARY:
==40910== in use at exit: 984 bytes in 3 blocks
==40910== total heap usage: 4 allocs, 1 frees, 1,456 bytes allocated
==40910==
==40910== LEAK SUMMARY:
==40910== definitely lost: 0 bytes in 0 blocks
==40910== indirectly lost: 0 bytes in 0 blocks
==40910== possibly lost: 0 bytes in 0 blocks
==40910== still reachable: 984 bytes in 3 blocks
==40910== suppressed: 0 bytes in 0 blocks
==40910== Rerun with --leak-check=full to see details of leaked memory
==40910==
==40910== For lists of detected and suppressed errors, rerun with: -s
==40910== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
Without the code this is certainly the easiest question to answer!
"unaddressable" = point to byte that do not belong to you.
valgrind warns you because probably the memory that you freed in memory is not yours (or, at least, it is no longer reserved for the use you had asked for), and then you could be using it for another thing and interpret a value that is not.
Why doesn't it break when you run without valgrind? Good, for starters - that's what you say. For onething your code is not doing appropriate error checking. So it may be breaking inside, so you wont notice it. All I could say is bad coding style may compile and runs without showing you any errors but in the background it maybe suffocating itself or the thing which it is running on.
Address 0x0 is not stack'd, malloc'd or (recently) free'd`
tells you you're dereferencing a NULL pointer (Address 0x0 ...) meaning fopen failed and returned 0/NULL.
Try fixing it? like..
-Check if returned fopen() valid FILE* to avoid undefined behavior when trying to read from input_file.
-Make sure that if fgets() succeeds (does not return NULL) to avoid undefined behavior.
PS: Read "The 8 Commandments for C Programmers"
2. Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.
6. If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest “it cannot happen to me”, the gods shall surely punish thee for thy arrogance.
Address 0x0 is not stack'd, malloc'd or (recently) free'd
That means you are using a NULL pointer ( NULL = (void*)0 AND 0 = 0x0 in hexadecimal). Try check if a pointer is NULL before using it.
Edit: if you are using "fopen", this function returns NULL if it cannot open the file.
For the purpose of my PhD thesis, I'm trying to trace the GAP Benchmark Suite using the SimPoints methodology and you may know, the first step to do so is to get Basic Block vectors for the application that you want to trace.
I've trying to use several methods available around such as experimental tools for valgrind:
valgrind --tool=exp-bbv /bin/ls
But I obtain errors such as this one when I'm trying to generate basic block vector files:
==177076== exp-bbv, a SimPoint basic block vector generator
==177076== NOTE: This is an Experimental-Class Valgrind Tool
==177076== Copyright (C) 2006-2015 Vince Weaver
==177076== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==177076== Command: /gpfs/scratch/bsc28/bsc28798/GAP/gapbs/pr -f /gpfs/scratch/bsc28/bsc28798/GAP/gapbs/benchmark/graphs/road.sg -i1000 -tle-4 -n16
==177076==
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x28 0xEF 0xC0 0xBF 0x0
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==177076== valgrind: Unrecognised instruction at address 0x4cb88a4.
==177076== at 0x4CB88A4: ??? (in /gpfs/apps/MN4/GCC/7.2.0/lib64/libstdc++.so.6.0.24)
==177076== by 0x400ECB9: call_init.part.0 (in /lib64/ld-2.22.so)
==177076== by 0x400EDA2: _dl_init (in /lib64/ld-2.22.so)
==177076== by 0x4001229: ??? (in /lib64/ld-2.22.so)
==177076== by 0x5: ???
==177076== by 0xFFEFFEE6A: ???
==177076== by 0xFFEFFEE94: ???
==177076== by 0xFFEFFEE97: ???
==177076== by 0xFFEFFEED7: ???
==177076== by 0xFFEFFEEDE: ???
==177076== by 0xFFEFFEEE5: ???
==177076== Your program just tried to execute an instruction that Valgrind
==177076== did not recognise. There are two possible reasons for this.
==177076== 1. Your program has a bug and erroneously jumped to a non-code
==177076== location. If you are running Memcheck and you just saw a
==177076== warning about a bad jump, it's probably your program's fault.
==177076== 2. The instruction is legitimate but Valgrind doesn't handle it,
==177076== i.e. it's Valgrind's fault. If you think this is the case or
==177076== you are not sure, please let us know and we'll try to fix it.
==177076== Either way, Valgrind will now raise a SIGILL signal which will
==177076== probably kill your program.
==177076==
==177076== Process terminating with default action of signal 4 (SIGILL)
==177076== Illegal opcode at address 0x4CB88A4
==177076== at 0x4CB88A4: ??? (in /gpfs/apps/MN4/GCC/7.2.0/lib64/libstdc++.so.6.0.24)
==177076== by 0x400ECB9: call_init.part.0 (in /lib64/ld-2.22.so)
==177076== by 0x400EDA2: _dl_init (in /lib64/ld-2.22.so)
==177076== by 0x4001229: ??? (in /lib64/ld-2.22.so)
==177076== by 0x5: ???
==177076== by 0xFFEFFEE6A: ???
==177076== by 0xFFEFFEE94: ???
==177076== by 0xFFEFFEE97: ???
==177076== by 0xFFEFFEED7: ???
==177076== by 0xFFEFFEEDE: ???
==177076== by 0xFFEFFEEE5: ???
==177076==
==177076==
==177076==
==177076== # Thread 1
I've also been trying to use the different options proposed on the SimPoints website, but it has been a dead-end so far. So here I am, asking the community, if you may know about a way to achieve this. :)
N.B.: Also, the workloads are running just fine on their own, it's when we want to trace them that we face issues.
Let us assume the binary you want to test is called bin and you have already created it. Then simply:
valgrind --tool=exp-bbv ./
I am trying to connect to mongodb with the C-API and my code seems to work fine. However, close inspection with Valgrind complains that I am doing illegal stuff.
My program accepts the parameter -h <hostname>, and then translates this string to a mongodb_uri and then tries to connect to mongodb:
*client_p = mongoc_client_new(host);
if (!*client_p) {
log_die("Failed to parse URI!");
}
My program runs as expected but when I inspect it with valgrind it the call to mongoc_client_new causes SIGSEGV:
==28775== Memcheck, a memory error detector
==28775== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==28775== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==28775== Command: ./coll2tde -h mongodb://localhost -d test -c testq
==28775==
aTrying to connect to mongodb://localhost
2014/12/25 22:22:21.0255: [28775]: DEBUG: cluster: Client initialized in direct mode.
==28775== Jump to the invalid address stated on the next line
==28775== at 0xFFFFFFFFFF600800: ???
==28775== by 0x402722: get_cursor (mongo.c:26)
==28775== by 0x402330: main (coll2tde.c:120)
==28775== Address 0xffffffffff600800 is not stack'd, malloc'd or (recently) free'd
==28775==
==28775==
==28775== Process terminating with default action of signal 11 (SIGSEGV)
==28775== Bad permissions for mapped region at address 0xFFFFFFFFFF600800
==28775== at 0xFFFFFFFFFF600800: ???
==28775== by 0x402722: get_cursor (mongo.c:26)
==28775== by 0x402330: main (coll2tde.c:120)
==28775==
==28775== HEAP SUMMARY:
==28775== in use at exit: 114,751 bytes in 3,194 blocks
==28775== total heap usage: 3,615 allocs, 421 frees, 177,386 bytes allocated
==28775==
==28775== LEAK SUMMARY:
==28775== definitely lost: 6,784 bytes in 1 blocks
==28775== indirectly lost: 2,968 bytes in 11 blocks
==28775== possibly lost: 1,462 bytes in 19 blocks
==28775== still reachable: 103,537 bytes in 3,163 blocks
==28775== suppressed: 0 bytes in 0 blocks
==28775== Rerun with --leak-check=full to see details of leaked memory
==28775==
==28775== For counts of detected and suppressed errors, rerun with: -v
==28775== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 6)
Killed
At the beginning I thought it's a problem with my code, but then I compile the example from mogoc_client documentation and saw the same behavior. I would like to know if it is a bug or can this be safely ignored.
After spending a couple of hours trying to figuring this issue, it turns out this is a problem with older versions of Valgrind (3.7 on Debian Wheezy). I compiled Valgrind in version 3.10.1 from upstream sources and this issue disappeared.
I'm having some problems using Valgrind to check for memory leaks (and also to understand a segfault I'm getting in fprintf), but it seems that somehow there are a couple o uninitialized values used that does not come from my code.
I'm new to debugging with debuggers so I may be missing something.
I know Valgrind is not confortable with my default GCC OpenMP (http://valgrind.org/docs/manual/drd-manual.html#drd-manual.openmp), but I'm using it and compilimg my code with -pedantic -Wall -static -O0 -g -fopenmp I get no errors.
However, when running Valgrind with
valgrind --leak-check=full --track-origins=yes --error-limit=no --log-file=./logfile ~/developing/trunk/gop.exe
I get in my logfile a lot of warnings starting with
==5944== Memcheck, a memory error detector
==5944== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==5944== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==5944== Command: /home/henrique/developing/trunk/gop.exe
==5944== Parent PID: 11534
==5944==
==5944== Syscall param set_robust_list(head) points to uninitialised byte(s)
==5944== at 0x4983DF: __pthread_initialize_minimal (nptl-init.c:369)
==5944== by 0x498920: (below main) (libc-start.c:146)
==5944== Address 0x4000bf0 is not stack'd, malloc'd or (recently) free'd
==5944== Uninitialised value was created
==5944== at 0x513A6A: brk (brk.c:32)
==5944== by 0x4ED4EB: sbrk (sbrk.c:54)
==5944== by 0x498C13: __libc_setup_tls (libc-tls.c:150)
==5944== by 0x498366: __pthread_initialize_minimal (nptl-init.c:296)
==5944== by 0x498920: (below main) (libc-start.c:146)
And then getting a lot of warnings (thousands!) similar to the one below
==5944== Conditional jump or move depends on uninitialised value(s)
==5944== at 0x4EF546: __linkin_atfork (register-atfork.c:119)
==5944== by 0x4BA5D3: ptmalloc_init (arena.c:388)
==5944== by 0x4BB283: malloc_hook_ini (hooks.c:32)
==5944== by 0x51842B: _dl_init_paths (dl-load.c:732)
==5944== by 0x4F097A: _dl_non_dynamic_init (dl-support.c:268)
==5944== by 0x4F1352: __libc_init_first (init-first.c:83)
==5944== by 0x49895B: (below main) (libc-start.c:165)
==5944== Uninitialised value was created
==5944== at 0x513A6A: brk (brk.c:32)
==5944== by 0x4ED4EB: sbrk (sbrk.c:54)
==5944== by 0x498C13: __libc_setup_tls (libc-tls.c:150)
==5944== by 0x498366: __pthread_initialize_minimal (nptl-init.c:296)
==5944== by 0x498920: (below main) (libc-start.c:146)
Am I missing something when compiling or running Valgrind? Or my code really have all these errors?
Thank you very much!
Some libraries do have a lot of little warnings like the ones you are showing.
I don't think they come from your code here seeing the names of the files where they occur.
You'll have to look somewhere else for your segfault. Try running it with gdb, look where it stops and print values around the error to see what's up.
Hope it helps :)
I'm writing a very basic SDL application, but when I run it through valgrind, it reports several lost blocks apparently related to the SDL library (before you ask it, I do call SDL_Quit, or more precisely I call atexit(SDL_Quit)). Here is an example:
==2525== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 107 of 131
==2525== at 0x4C25502: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2525== by 0x644244A: ??? (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x6442989: ??? (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x64440A2: ??? (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x6444915: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x6462B5F: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x644C325: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x644C467: _XlcCurrentLC (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x644C4BD: XSetLocaleModifiers (in /usr/lib/libX11.so.6.3.0)
==2525== by 0x4E69EED: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==2525== by 0x4E6A57F: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==2525== by 0x4E59E00: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
I searched here on StackOverflow and found a similar question. The answer was that apparently, there are some small buffers allocated within the library which the writers never care to free. My question is, what is the motivation of such an approach? Why allocate something and then deliberately not free() it?
If the buffers are needed till the end of the program there is no need to free them. When a program exits all memory it was using is freed by the OS anyway. If the program bothered to free the blocks before exiting it would only serve to slow down the exiting of the program.