In my program I'm using GNU Readline and the functions from that library causes some leaks. While using Valgrind I don't want to see those leaks. Can I somehow block some functions?
I was getting lots of this kind of leak warnings from using valgrind --leak-check=full --show-leak-kinds=all ./program
==2376== 28,784 bytes in 7 blocks are still reachable in loss record 57 of 57
==2376== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2376== by 0x489500C: xmalloc (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x4873A91: rl_make_bare_keymap (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x487AD79: rl_generic_bind (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x487CA92: rl_parse_and_bind (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x487CC6C: ??? (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x486F228: rl_initialize (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x486F4AF: readline (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.0)
==2376== by 0x10B6B5: main (main.c:77)
I made a file named supp.supp and wrote in it:
{
ignore_libreadline_leaks
Memcheck:Leak
...
obj:*/libreadline.so.*
}
After this, I added --suppressions=supp.supp flag. All leak errors from libreadline is now suppressed.
Related
When I run perf test, one test that fails inside a Ubuntu 21.04 Docker container but succeeds on its Ubuntu 21.04 host is 26: Object code reading. It seems like it could be related to some issues with perf in the container, e.g. dwarf unwinding doesn't work at all.
The verbose output is
26: Object code reading :
--- start ---
test child forked, pid 92383
maps__set_modules_path_dir: cannot open /lib/modules/5.11.0-22-generic dir
Problems setting modules path maps, continuing anyway...
maps__set_modules_path_dir: cannot open /lib/modules/5.11.0-22-generic dir
Problems setting modules path maps, continuing anyway...
Looking at the vmlinux_path (8 entries long)
Failed to open /proc/kcore. Note /proc/kcore requires CAP_SYS_RAWIO capability to access.
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
/proc/{kallsyms,modules} inconsistency while looking for "[bpf]" module!
Using /proc/kallsyms for symbols
Parsing event 'cycles:u'
mmap size 528384B
Reading object code for memory address: 0x7fd8f3dececb
File is: /usr/lib/x86_64-linux-gnu/libc-2.33.so
On file address is: 0x10decb
test child finished with -1
---- end ----
Object code reading: FAILED!
What does the test test for exactly, and why does it fail inside the container? I'm running Docker with --privileged.
I have a problem figuring out why ASAN gives this output, why I can't see where and in what line the bug is in my code, is this bug even in my code as it says or is it in some libraries that is used by the program?
This is how I build my project :
CC=clang CXX=clang++ meson -Db_sanitize=address -Db_lundef=false
build-clang
and then I configure the env values and run the executable like this :
ASAN_OPTIONS=symbolize=1
ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer ./executable
And yes that is a valid path for llvm-sybolizer
So is there a way for me to know what does executable+0x431340 mean and where it points to in my code?
=================================================================
==13110==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16384 byte(s) in 1 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff16a2ccab8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51ab8)
Direct leak of 4352 byte(s) in 17 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff165e518ed (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d8ed)
Direct leak of 3840 byte(s) in 6 object(s) allocated from:
#0 0x4e17c0 in realloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e17c0)
#1 0x7ff165e51998 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d998)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff16a2ccab8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51ab8)
#2 0x7ff168b5910c in g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x1010c)
Indirect leak of 10016 byte(s) in 313 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff165e3ffef (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0xbfef)
Indirect leak of 4887 byte(s) in 405 object(s) allocated from:
#0 0x43db60 in strdup (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x43db60)
#1 0x7ff165e512f4 in FcValueSave (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d2f4)
Indirect leak of 4320 byte(s) in 135 object(s) allocated from:
#0 0x4e1568 in calloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1568)
#1 0x7ff165e51fd8 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1dfd8)
Indirect leak of 2400 byte(s) in 75 object(s) allocated from:
#0 0x4e1568 in calloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1568)
#1 0x7ff165e515c4 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d5c4)
Indirect leak of 576 byte(s) in 18 object(s) allocated from:
#0 0x4e1568 in calloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1568)
#1 0x7ff165e51440 (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1d440)
Indirect leak of 144 byte(s) in 3 object(s) allocated from:
#0 0x4e1340 in __interceptor_malloc (/home/maysara/Desktop/testscreen/build-clang/src/excutable+0x4e1340)
#1 0x7ff165e4bacd in FcLangSetCreate (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x17acd)
SUMMARY: AddressSanitizer: 46943 byte(s) leaked in 974 allocation(s).
In order to resolve the code addresses to source code locations, you need to compile the code with debug symbols enabled, e.g. with -g on the compiler command line or the commonly with build systems the environment variables CFLAGS and CXXFLAGS set accordingly:
CFLAGS="-g"
CXXFLAGS="-g"
That needs to be done for the code actually referenced, meaning here for example not only the code of executable, but also the linked libraries like glib, fontconfig, etc. if you want all addresses resolved.
Since these libraries are probably installed through a system package manager, you would need to look in your distribution's documentation how to install debug symbols. For Ubuntu, for example, there are usually variants of packages with an -dbg suffix.
In any case your stack traces do not look very helpful anyway, so it is not clear that finding the source code locations will be any help to you. You might want to recompile your executable with -fno-omit-frame-pointer and/or set the environment variable ASAN_OPTIONS=fast_unwind_on_malloc=0 when running the executable to try and improve them. See also the ASAN faq.
I just know when gdb attach to a process, I can use p $_siginfo._sifields._sigfault.si_addr to show what address caused a segfault.
But, how to do in a core dump file?
I try it in a core dump file:
(gdb) p $_siginfo._sifields._sigfault.si_addr
Unable to read siginfo
I have a core dump that shows a thread dying from a SIGBUS signal while executing mov %r15d,0xa0(%rsp). That seems to tell me that it died because it ran out of thread stack.
But how can I prove it? I cannot seem to find a GDB command to display thread information besides thread backtraces. In this case there is no backtrace. It shows the current function and then 0x0000000000000000. Yet another indication of stack corruption, I think.
I don't have a copy of /proc/[pid]/maps from when the program died. Is there anything in GDB or in the core file I can look at to find the base of each thread stack?
That seems to tell me that it died because it ran out of thread stack.
Very likely
But how can I prove it?
(gdb) p/x $rsp
$1 = 0x7fffc5791000
(gdb) info target
Symbols from "a.out".
Local core dump file:
`core', file type elf64-x86-64.
0x0000000000400000 - 0x0000000000401000 is load1
...
0x00007faaf2240000 - 0x00007faaf2241000 is load14
0x00007fffc5791000 - 0x00007fffc5f91000 is load15
0x00007fffc5faf000 - 0x00007fffc5fb0000 is load16
0xffffffffff600000 - 0xffffffffff600000 is load17
Local exec file:
...
Note how $rsp is at the (low) end of the load15 segment, and there is no mapping that "covers" $rsp-8
all.
I'm a kernel newbie. I want to know how to get useful infomations from painc such as which line or which function is wrong.
For example, following is a panic-output about usb hiddev, how to read it? Thanks.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [<ffffffff813b4aa1>] free_async+0xa1/0x100
PGD 2326c9067 PUD 230f4c067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1d.2/usb8/8-2/speed
CPU 3
Modules linked in: ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp l]
Pid: 2400, comm: lsusb Tainted: G I--------------- 2.6.32-296.el664fixes.3.x86_64 #1 Dell Inc. OptiPlN
RIP: 0010:[<ffffffff813b4aa1>] do_IRQ: 0.97 No irq handler for vector (irq -1)
[Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 186 is 53003c)
�Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
setfont: KDFONTOP: Invalid argument
Free memory/Total memory (free %): 78672 / 114884 ( 68.4795 )
Loading dm-mod.ko module
Loading dm-log.ko module
Loading dm-region-hash.ko module
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Loading freq_table.ko module
Loading mperf.ko module
Loading ipt_REJECT.ko module
Loading nf_defrag_ipv4.ko module
Loading ip_tables.ko module
Loading nf_conntrack.ko module
Loading ip6_tables.ko module
Loading ipv6.ko module
Loading fat.ko module
Loading macvlan.ko module
Loading tun.ko module
Loading kvm.ko module
Loading uinput.ko module
Loading parport.ko module
Loading dcdbas.ko module
Loading microcode.ko module
The panic itself is actually quite accurate as is;
BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [] free_async+0xa1/0x100
Tells already that the function where the problem happened is free_async and that function is exactly 0x100 bytes long and the crash happened at offset 0xa1. You need to map that offset into the exact line of code, but that now depends a bit on your environment how to do it.
Sometimes manual code review already will show what line has pointer manipulations, so you can do it just by reviewing that function.
Then the next question is that, why do you have a NULL-pointer there?