How can I tell valgrind to stop showing any kind of error related to a certain library? I got lots of reports that look like this:
==24152== Invalid write of size 8
==24152== at 0xD9FF876: ??? (in /usr/lib64/dri/fglrx_dri.so)
==24152== by 0x110647AF: ???
==24152== Address 0x7f3c98553f20 is not stack'd, malloc'd or (recently) free'd
I could prune them by the address (0x7fxxxxxxxxxx is not something that is allocated at userland), but my valgrind build seems not to accept --ignore-ranges=0x7f0000000000-0x7fffffffffff
You can generate suppression-lists using --gen-suppressions=all. Then you can add those to some .supp file under lib/valgrind.
Related
I want to generate a suppressions file with --gen-suppressions in valgrind.
However, I do not want to have to go through thousands of lines of output the cut and paste out the suppressions and remove the valgrind stack traces / other valgrind output, and resolve .
Is there a way to do this easily? This seems like a very basic use case...
// I want this part vvvvv
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
fun:strdup
fun:_XlcCreateLC
fun:_XlcDefaultLoader
fun:_XOpenLC
fun:_XrmInitParseInfo
obj:/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
fun:XrmGetStringDatabase
obj:/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
fun:XGetDefault
fun:GetXftDPI
fun:X11_InitModes_XRandR
fun:X11_InitModes
fun:X11_VideoInit
}
// I do not want this part vvvv
==187526== 2 bytes in 1 blocks are still reachable in loss record 2 of 137
==187526== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==187526== by 0x4B7C50E: strdup (strdup.c:42)
==187526== by 0x5922D81: _XlcResolveLocaleName (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==187526== by 0x5926387: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==187526== by 0x5925956: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==187526== by 0x592615C: _XlcCreateLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==187526== by 0x5943664: _XlcDefaultLoader (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==187526== by 0x592D995: _XOpenLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
It is quite unlikely that all of the suppressions are different.
If you create a suppression like
{
XINIT-1
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
fun:strdup
fun:_XlcCreateLC
fun:_XlcDefaultLoader
fun:_XOpenLC
fun:_XrmInitParseInfo
obj:/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
}
Then re-run. Typically the error count will go down very quickly and you will only need to add a fairly small number of suppressions (single or low double digits).
(you need to apply your knowledge of the code and libs(s) to get a sensible stack depth for suppressions - too many stack entries and the suppression will be too specific and you need more suppressions, too few and you risk suppressing real problems).
Due to CRC( Autosar)issue for a particular NvBlock, "NVM_E_INTEGRITY_FAILED" Error was observed during "NVM_ReadAll()".
I tried to debug but couldn't root cause the issue.
Out of all the blocks only one NvBlock has the crc issue and obviously causing the NNM_Readll to fail("NVM_REQ_NOT_OK").
Please suggest the best method to debug this issue.
Thank you Lundin and Kesselhaus. Its seems the SPI dirver has the issue in reading the data from Eeprom for that particular block (block size greater than 1k). The calculated CRC has different value compared to actual CRC value. Thus NVM_Integrity Error is set.
Is it possible to lookup the location of a function using ELF? Similar to what
void *f = dlopen(NULL,..);
void *func = dlsym(f, "myfunc");
does, but without requiring -rdynamic during compilation?
I can see using nm that the naming of the items is still present in a compiled binary?:
0000000000400716 T lookup
0000000000400759 T main
Can I use this information to locate the items once the program is loaded into memory?
Can I use this information to locate the items once the program is loaded into memory?
You sure can: iterate over all symbols in the a.out until you find the matching one. Example code to iterate over symbols is here. Or use libelf.
If you need to perform multiple symbol lookups, iterate once (slow) over all symbols, build a map from symbol name to its address, and perform lookups using that map.
Update:
The example you point to seems incomplete? It uses data and elf, where are they coming from?
Yes, you need to apply a little bit of elbow grease to that example.
The data is location in memory where the a.out is read into, or (better) mmaped.
You can either mmap the a.out yourself, or find the existing mapping via e.g. getauxval(AT_PHDR) rounded down to page size.
The ehdr is (ElfW(Ehdr) *)data (that is, data cast to Elf32_Ehdr or Elf64_Ehdr as appropriate.
If this is not clear, then you probably should just use libelf, which takes care of the details for you.
Also, does ELF only allow me to find the name of the symbol, or can it actually give me the pointer to the in memory location of the symbol?
It can give you both: str + sym[i].st_name is the name, sym[i].st_value is the pointer (the value displayed by nm).
(presumably the e.g. 0000000000400716 is some relative base address, not the actual in memory location, right?)
No, actually (for this binary) it's the absolute address.
Position-independent binaries do use relative addresses (so you'll need something like getauxval mentioned above to find the base location of such executable), but this particular binary looks like ET_EXEC (use readelf -h a.out to verify this). The address 0x400000 is typical address for loading of non-PIE executables on Linux x86_64 (which is probably what your system is).
I am running into a problem that appears to be due to a stack overflow. When I run the application under Valgrind, I get the following errors:
Thread 75:
Invalid write of size 4
at 0x833FBF6: <Class Name>::<Method Name>(short, short&) (<File Name>:692)
Address 0x222d75c0 is on thread 75's stack
Process terminating with default action of signal 11 (SIGSEGV): dumping core
Bad permissions for mapped region at address 0x222D6000
at 0x4022BA3: memset (mc_replace_strmem.c:586)
by 0x833FC80: <Class Name>::<Method Name>(short, short&) (<File Name>:708)
If I open the core file in gdb, go to frame 1 where the memset is being called, and do an "info registers", it shows that $esp = 0x222d5210 and $ebp = 0x222d75c8.
Doesn't that seem to indicate that the stack would include memory at addres 0x222D6000? If that's true, then why would we get the "Bad permissions" error?
The other odd thing is that line 692 of the source file is the very first line of the method (i.e., "void ::(short var1, short &var2)"). So, why would we get an invalid write at that point?
As I said, it seems to be a case of running out of stack space, but even if we use the "limit stacksize" command to increase the amount of allocated stack space, we still encounter the same problem.
I've been beating my head against the wall for several days trying to debug this problem. Any advice would be appreciated.
It turns out that this problem was due to a stack overflow after all. I didn't realize that the code that spawned the thread that was causing the problem explicitly set the size of the stack to be used by the thread. That's why changing the value used by the "limit stacksize" command didn't make a difference. Once, I modified the code that set the stack size to increase the amount of memory allocated, the problem went away.
What you could do is to activate the Valgrind gdbserver, and
attach using gdb+vgdb to your program running under Valgrind.
You can then use various valgrind monitor commands to have more
info about the problem. E.g. look again at the register values,
use 'monitor v.info scheduler' to see the stack trace and the stack size, ...
Full list of monitor commands with memcheck+valgrind can be found at
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
and
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.valgrind-monitor-commands
I'm using libdc1394-2.2 for camera Bumblebee2.
However, when I try to release bandwith with code below:
if (dc1394_iso_release_bandwidth(camera, val)==DC1394_SUCCESS)
printf( "Succesfully released %d bytes of bandwidth\n", val);
Throws the next error:
undefined reference to `dc1394_iso_release_bandwidth'
However, the function 'dc1394_iso_release_bandwidth', is included in 'iso.h' and this header is included in the main program.
Someone knows how solve the problem?
You're correct, that function is indeed listed in the dc1394-2 stream iso.h header file and with no complex conditional compilation which may cause it to not appear in your translation unit.
One thing that may be an issue is the rather common name iso.h - I'd modify your g++ compilation statement to include a -H flag, which should list the headers being loaded up. It's possible that the iso.h header file you're loading is not actually the dc1394 one.
A long shot, I know, but worth checking if only to discount the possibility.