-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
need better compiler error/diagnistics output #1
Comments
Closing this as the clang frontend has much better diagnostics now. |
Merged
drzaeus77
pushed a commit
that referenced
this issue
May 10, 2017
Fix computation of LUAJIT_INCLUDE_DIR
yonghong-song
added a commit
that referenced
this issue
Jan 10, 2018
Fixing issue #1515. Currently, each usdt probe (provider, probe_name) can only have locations from the single binary. It is possible that USDT probes are defined in a header file which eventually causes the same usdt probe having locations in several different binary/shared_objects. In such cases, we are not able to attach the same bpf program to all these locations. This patch addresses this issue by defining each location to be `bin_path + addr_offset` vs. previous `addr_offset` only. This way, each internal Probe class can represent all locations for the same (provider, probe_name) pair. The `tplist.py` output is re-organized with the (provider, probe_name) in the top level like below: ``` ... rtld:lll_futex_wake [sema 0x0] location #1 /usr/lib64/ld-2.17.so 0xaac8 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #2 /usr/lib64/ld-2.17.so 0xe9b9 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #3 /usr/lib64/ld-2.17.so 0xef3b argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 ... ``` Tested with the following commands ``` tplist.py trace.py -p <pid> 'u::probe "arg1 = %d", arg1' trace.py u:<binary_path>:probe "arg1 = %d", arg1' argdist.py -p <pid> 'u::probe():s64:arg1' argdist.py -C 'u:<binary_path>:probe():s64:arg1' funccount.py -p <pid> 'u:<binary_path>:probe' funccount.py 'u:<binary_path>:probe' ``` Signed-off-by: Yonghong Song <[email protected]>
yonghong-song
added a commit
that referenced
this issue
Jan 11, 2018
Fixing issue #1515. Currently, each usdt probe (provider, probe_name) can only have locations from the single binary. It is possible that USDT probes are defined in a header file which eventually causes the same usdt probe having locations in several different binary/shared_objects. In such cases, we are not able to attach the same bpf program to all these locations. This patch addresses this issue by defining each location to be `bin_path + addr_offset` vs. previous `addr_offset` only. This way, each internal Probe class can represent all locations for the same (provider, probe_name) pair. The `tplist.py` output is re-organized with the (provider, probe_name) in the top level like below: ``` ... rtld:lll_futex_wake [sema 0x0] location #1 /usr/lib64/ld-2.17.so 0xaac8 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #2 /usr/lib64/ld-2.17.so 0xe9b9 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #3 /usr/lib64/ld-2.17.so 0xef3b argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 ... ``` Tested with the following commands ``` tplist.py trace.py -p <pid> 'u::probe "arg1 = %d", arg1' trace.py u:<binary_path>:probe "arg1 = %d", arg1' argdist.py -p <pid> 'u::probe():s64:arg1' argdist.py -C 'u:<binary_path>:probe():s64:arg1' funccount.py -p <pid> 'u:<binary_path>:probe' funccount.py 'u:<binary_path>:probe' ``` Signed-off-by: Yonghong Song <[email protected]>
yonghong-song
added a commit
that referenced
this issue
Jan 11, 2018
Fixing issue #1515. Currently, each usdt probe (provider, probe_name) can only have locations from the single binary. It is possible that USDT probes are defined in a header file which eventually causes the same usdt probe having locations in several different binary/shared_objects. In such cases, we are not able to attach the same bpf program to all these locations. This patch addresses this issue by defining each location to be `bin_path + addr_offset` vs. previous `addr_offset` only. This way, each internal Probe class can represent all locations for the same (provider, probe_name) pair. The `tplist.py` output is re-organized with the (provider, probe_name) in the top level like below: ``` ... rtld:lll_futex_wake [sema 0x0] location #1 /usr/lib64/ld-2.17.so 0xaac8 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #2 /usr/lib64/ld-2.17.so 0xe9b9 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #3 /usr/lib64/ld-2.17.so 0xef3b argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 ... ``` Tested with the following commands ``` tplist.py trace.py -p <pid> 'u::probe "arg1 = %d", arg1' trace.py u:<binary_path>:probe "arg1 = %d", arg1' argdist.py -p <pid> 'u::probe():s64:arg1' argdist.py -C 'u:<binary_path>:probe():s64:arg1' funccount.py -p <pid> 'u:<binary_path>:probe' funccount.py 'u:<binary_path>:probe' ``` Signed-off-by: Yonghong Song <[email protected]>
yonghong-song
added a commit
that referenced
this issue
Jan 12, 2018
Fixing issue #1515. Currently, each usdt probe (provider, probe_name) can only have locations from the single binary. It is possible that USDT probes are defined in a header file which eventually causes the same usdt probe having locations in several different binary/shared_objects. In such cases, we are not able to attach the same bpf program to all these locations. This patch addresses this issue by defining each location to be `bin_path + addr_offset` vs. previous `addr_offset` only. This way, each internal Probe class can represent all locations for the same (provider, probe_name) pair. The `tplist.py` output is re-organized with the (provider, probe_name) in the top level like below: ``` ... rtld:lll_futex_wake [sema 0x0] location #1 /usr/lib64/ld-2.17.so 0xaac8 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #2 /usr/lib64/ld-2.17.so 0xe9b9 argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 location #3 /usr/lib64/ld-2.17.so 0xef3b argument #1 8 unsigned bytes @ di argument #2 4 signed bytes @ 1 argument #3 4 signed bytes @ 0 ... ``` Tested with the following commands ``` tplist.py trace.py -p <pid> 'u::probe "arg1 = %d", arg1' trace.py u:<binary_path>:probe "arg1 = %d", arg1' argdist.py -p <pid> 'u::probe():s64:arg1' argdist.py -C 'u:<binary_path>:probe():s64:arg1' funccount.py -p <pid> 'u:<binary_path>:probe' funccount.py 'u:<binary_path>:probe' ``` Signed-off-by: Yonghong Song <[email protected]>
banh-gao
pushed a commit
to banh-gao/bcc
that referenced
this issue
Jun 21, 2018
Fixing issue iovisor#1515. Currently, each usdt probe (provider, probe_name) can only have locations from the single binary. It is possible that USDT probes are defined in a header file which eventually causes the same usdt probe having locations in several different binary/shared_objects. In such cases, we are not able to attach the same bpf program to all these locations. This patch addresses this issue by defining each location to be `bin_path + addr_offset` vs. previous `addr_offset` only. This way, each internal Probe class can represent all locations for the same (provider, probe_name) pair. The `tplist.py` output is re-organized with the (provider, probe_name) in the top level like below: ``` ... rtld:lll_futex_wake [sema 0x0] location iovisor#1 /usr/lib64/ld-2.17.so 0xaac8 argument iovisor#1 8 unsigned bytes @ di argument iovisor#2 4 signed bytes @ 1 argument iovisor#3 4 signed bytes @ 0 location iovisor#2 /usr/lib64/ld-2.17.so 0xe9b9 argument iovisor#1 8 unsigned bytes @ di argument iovisor#2 4 signed bytes @ 1 argument iovisor#3 4 signed bytes @ 0 location iovisor#3 /usr/lib64/ld-2.17.so 0xef3b argument iovisor#1 8 unsigned bytes @ di argument iovisor#2 4 signed bytes @ 1 argument iovisor#3 4 signed bytes @ 0 ... ``` Tested with the following commands ``` tplist.py trace.py -p <pid> 'u::probe "arg1 = %d", arg1' trace.py u:<binary_path>:probe "arg1 = %d", arg1' argdist.py -p <pid> 'u::probe():s64:arg1' argdist.py -C 'u:<binary_path>:probe():s64:arg1' funccount.py -p <pid> 'u:<binary_path>:probe' funccount.py 'u:<binary_path>:probe' ``` Signed-off-by: Yonghong Song <[email protected]>
Closed
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Nov 27, 2023
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project cvector.h comes from c-vector project commit d3f3156373b0587336ac7ee1568755d6cf93dd39 https://github.com/eteran/c-vector uthash.h comes from uthash project commit bf15263081be6229be31addd48566df93921cb46 https://github.com/troydhanson/uthash This tool detect and report dangling pointers periodically Usage: lsan [OPTION...] Detect memory leak resulting from dangling pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument lsan -c "a.out arg" # Detect leaks on a.out with argument -c, --command=COMMAND Execute and trace the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Set pid -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the world during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report example: $ sudo ./lsan -c a.out -s suppr.txt Info: Execute child process: a.out Info: execute command: a.out(pid 8335) [2022-07-19 16:07:26] Print leaks: Could not open [uprobes] 4 bytes direct leak found in 1 allocations from stack id(19863) iovisor#1 0x00564465ed71bf foo iovisor#2 0x00564465ed721b main iovisor#3 0x007fc0a33f7d90 __libc_init_first [2022-07-19 16:07:36] Print leaks: 8 bytes direct leak found in 2 allocations from stack id(19863) iovisor#1 0x00564465ed71bf foo iovisor#2 0x00564465ed721b main iovisor#3 0x007fc0a33f7d90 __libc_init_first [2022-07-19 16:07:46] Print leaks: 12 bytes direct leak found in 3 allocations from stack id(19863) iovisor#1 0x00564465ed71bf foo iovisor#2 0x00564465ed721b main iovisor#3 0x007fc0a33f7d90 __libc_init_first Source code of test program: \#include <stdio.h> \#include <stdlib.h> \#include <unistd.h> int* foo() { int *tmp = malloc(sizeof(int)); *tmp = 99; return tmp; } int* bar() { int *tmp = malloc(sizeof(int)); *tmp = 22; return tmp; } int main() { int *a = NULL; while (1) { a = foo(); printf("%d\n", *a); a = bar(); free(a); sleep(10); } }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Dec 21, 2023
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree --help Usage: doublefree [OPTION...] Detect and report double free error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument doublefree -c "a.out arg" # Detect doublefree on a.out with argument -c, --command=COMMAND Execute and trace the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Set pid -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c \#include <unistd.h> \#include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(50); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ ./a.out & [1] 5718 $ sudo ./doublefree -p 5718 2023-Dec-21 10:29:01 WARN Is this process alive? pid: 5718 iovisor#1 Found double free... Allocation happended on stack_id: 19655 iovisor#1 0x0000557abf0824 foo+0x10 (/home/bojun/test/doublefree_generator/a.out+0x824) iovisor#2 0x0000557abf0868 main+0x1c (/home/bojun/test/doublefree_generator/a.out+0x868) iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730) First deallocation happended on stack_id: 52798 iovisor#1 0x00007f9911f614 free+0 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x8f614) iovisor#2 0x0000557abf0880 main+0x34 (/home/bojun/test/doublefree_generator/a.out+0x880) iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730) Second deallocation happended on stack_id: 14228 iovisor#1 0x00007f9911f614 free+0 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x8f614) iovisor#2 0x0000557abf0894 main+0x48 (/home/bojun/test/doublefree_generator/a.out+0x894) iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Dec 21, 2023
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree --help Usage: doublefree [OPTION...] Detect and report double free error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument doublefree -c "a.out arg" # Detect doublefree on a.out with argument -c, --command=COMMAND Execute and trace the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Set pid -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c \#include <unistd.h> \#include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(50); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ ./a.out & [1] 5718 $ sudo ./doublefree -p 5718 2023-Dec-21 10:29:01 WARN Is this process alive? pid: 5718 \iovisor#1 Found double free... Allocation happended on stack_id: 19655 \iovisor#1 0x0000557abf0824 foo+0x10 (/home/bojun/test/doublefree_generator/a.out+0x824) \iovisor#2 0x0000557abf0868 main+0x1c (/home/bojun/test/doublefree_generator/a.out+0x868) \iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) \iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) \iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730) First deallocation happended on stack_id: 52798 \iovisor#1 0x00007f9911f614 free+0 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x8f614) \iovisor#2 0x0000557abf0880 main+0x34 (/home/bojun/test/doublefree_generator/a.out+0x880) \iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) \iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) \iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730) Second deallocation happended on stack_id: 14228 \iovisor#1 0x00007f9911f614 free+0 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x8f614) \iovisor#2 0x0000557abf0894 main+0x48 (/home/bojun/test/doublefree_generator/a.out+0x894) \iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) \iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) \iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Dec 21, 2023
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree --help Usage: doublefree [OPTION...] Detect and report double free error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument doublefree -c "a.out arg" # Detect doublefree on a.out with argument -c, --command=COMMAND Execute and trace the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Set pid -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(50); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ ./a.out & [1] 5718 $ sudo ./doublefree -p 5718 2023-Dec-21 10:29:01 WARN Is this process alive? pid: 5718 iovisor#1 Found double free... Allocation happended on stack_id: 19655 iovisor#1 0x0000557abf0824 foo+0x10 (/home/bojun/test/doublefree_generator/a.out+0x824) iovisor#2 0x0000557abf0868 main+0x1c (/home/bojun/test/doublefree_generator/a.out+0x868) iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730) First deallocation happended on stack_id: 52798 iovisor#1 0x00007f9911f614 free+0 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x8f614) iovisor#2 0x0000557abf0880 main+0x34 (/home/bojun/test/doublefree_generator/a.out+0x880) iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730) Second deallocation happended on stack_id: 14228 iovisor#1 0x00007f9911f614 free+0 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x8f614) iovisor#2 0x0000557abf0894 main+0x48 (/home/bojun/test/doublefree_generator/a.out+0x894) iovisor#3 0x00007f990b7780 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27780) iovisor#4 0x00007f990b7858 __libc_start_main+0x98 (/usr/lib/aarch64-linux-gnu/libc.so.6+0x27858) iovisor#5 0x0000557abf0730 _start+0x30 (/home/bojun/test/doublefree_generator/a.out+0x730)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Dec 21, 2023
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree --help Usage: doublefree [OPTION...] Detect and report double free error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute and trace the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Set pid -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(50); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ ./a.out & [1] 368729 $ sudo ./doublefree -p 368729 Detecting doublefree on process id: 368729 2023-Dec-21 13:36:03 WARN Is this process alive? pid: 368729 iovisor#1 Found double free... Allocation happended on stack_id: 57880 iovisor#1 0x00560c7d49519b foo+0x12 (/home/bojun/bcc/libbpf-tools/a.out+0x119b) iovisor#2 0x00560c7d4951e3 main+0x27 (/home/bojun/bcc/libbpf-tools/a.out+0x11e3) iovisor#3 0x007f306c629d90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) First deallocation happended on stack_id: 57771 iovisor#1 0x007f306c6a53e0 free+0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00560c7d4951fd main+0x41 (/home/bojun/bcc/libbpf-tools/a.out+0x11fd) iovisor#3 0x007f306c629d90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) Second deallocation happended on stack_id: 41685 iovisor#1 0x007f306c6a53e0 free+0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00560c7d495213 main+0x57 (/home/bojun/bcc/libbpf-tools/a.out+0x1213) iovisor#3 0x007f306c629d90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Dec 21, 2023
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree --help Usage: doublefree [OPTION...] Detect and report double free error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute and trace the specified command -i, --interval=INTERVAL Set interval in second to detect doublefree -p, --pid=PID Set pid to trace -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(50); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ ./a.out & [1] 368729 $ sudo ./doublefree -p 368729 Detecting doublefree on process id: 368729 2023-Dec-21 13:36:03 WARN Is this process alive? pid: 368729 iovisor#1 Found double free... Allocation happended on stack_id: 57880 iovisor#1 0x00560c7d49519b foo+0x12 (/home/bojun/bcc/libbpf-tools/a.out+0x119b) iovisor#2 0x00560c7d4951e3 main+0x27 (/home/bojun/bcc/libbpf-tools/a.out+0x11e3) iovisor#3 0x007f306c629d90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) First deallocation happended on stack_id: 57771 iovisor#1 0x007f306c6a53e0 free+0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00560c7d4951fd main+0x41 (/home/bojun/bcc/libbpf-tools/a.out+0x11fd) iovisor#3 0x007f306c629d90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) Second deallocation happended on stack_id: 41685 iovisor#1 0x007f306c6a53e0 free+0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00560c7d495213 main+0x57 (/home/bojun/bcc/libbpf-tools/a.out+0x1213) iovisor#3 0x007f306c629d90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Jan 25, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report double free error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument doublefree -c "a.out arg" # Detect doublefree on a.out with argument -c, --command=COMMAND Execute and trace the specified command -p, --pid=PID Set pid -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(10); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ sudo ./doublefree -c a.out 2024-Jan-25 13:19:32 INFO Execute child process: a.out 2024-Jan-25 13:19:32 INFO execute command: a.out(pid 108346) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x0055f7b647f19b foo+0x12 iovisor#2 0x0055f7b647f1e3 main+0x27 iovisor#3 0x007f0ae6e29d90 First deallocation: iovisor#1 0x007f0ae6ea53e0 free+0 iovisor#2 0x0055f7b647f1fd main+0x41 iovisor#3 0x007f0ae6e29d90 Second deallocation: iovisor#1 0x007f0ae6ea53e0 free+0 iovisor#2 0x0055f7b647f213 main+0x57 iovisor#3 0x007f0ae6e29d90 ^C2024-Jan-25 13:19:32 ERROR Failed to poll perf_buffer $
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Feb 29, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report doublefree error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute the command and detect doublefree -p, --pid=PID Detect doublefree on the specified process -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(10); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ sudo ./doublefree -c a.out 2024-Feb-29 15:10:46 INFO Execute command: a.out(pid 216625) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x005586f530f19b foo+0x12 iovisor#2 0x005586f530f1e3 main+0x27 iovisor#3 0x007f6990c29d90 [unknown] First deallocation: iovisor#1 0x007f6990ca53e0 free+0 iovisor#2 0x005586f530f1fd main+0x41 iovisor#3 0x007f6990c29d90 [unknown] Second deallocation: iovisor#1 0x007f6990ca53e0 free+0 iovisor#2 0x005586f530f213 main+0x57 iovisor#3 0x007f6990c29d90 [unknown] ^C $
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Feb 29, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report doublefree error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute the command and detect doublefree -p, --pid=PID Detect doublefree on the specified process -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(10); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ sudo ./doublefree -c a.out 2024-Feb-29 15:10:46 INFO Execute command: a.out(pid 216625) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x005586f530f19b foo+0x12 iovisor#2 0x005586f530f1e3 main+0x27 iovisor#3 0x007f6990c29d90 [unknown] First deallocation: iovisor#1 0x007f6990ca53e0 free+0 iovisor#2 0x005586f530f1fd main+0x41 iovisor#3 0x007f6990c29d90 [unknown] Second deallocation: iovisor#1 0x007f6990ca53e0 free+0 iovisor#2 0x005586f530f213 main+0x57 iovisor#3 0x007f6990c29d90 [unknown] ^C $
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Mar 1, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report doublefree error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute the command and detect doublefree -p, --pid=PID Detect doublefree on the specified process -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(10); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ sudo ./doublefree -c a.out 2024-Feb-29 15:10:46 INFO Execute command: a.out(pid 216625) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x005586f530f19b foo+0x12 iovisor#2 0x005586f530f1e3 main+0x27 iovisor#3 0x007f6990c29d90 [unknown] First deallocation: iovisor#1 0x007f6990ca53e0 free+0 iovisor#2 0x005586f530f1fd main+0x41 iovisor#3 0x007f6990c29d90 [unknown] Second deallocation: iovisor#1 0x007f6990ca53e0 free+0 iovisor#2 0x005586f530f213 main+0x57 iovisor#3 0x007f6990c29d90 [unknown] ^C $
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Mar 14, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project cvector.h comes from c-vector project commit d3f3156373b0587336ac7ee1568755d6cf93dd39 https://github.com/eteran/c-vector uthash.h comes from uthash project commit bf15263081be6229be31addd48566df93921cb46 https://github.com/troydhanson/uthash This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -c a.out 2024-Mar-14 11:47:18 INFO execute command: a.out(pid 256995) [2024-03-14 12:38:36] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(39518) iovisor#1 0x00564a94cc1250 baz+0x1c iovisor#2 0x00564a94cc12d7 main+0x73 iovisor#3 0x007faf6f029d90 [unknown] [2024-03-14 12:38:46] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(39518) iovisor#1 0x00564a94cc1250 baz+0x1c iovisor#2 0x00564a94cc12d7 main+0x73 iovisor#3 0x007faf6f029d90 [unknown] ^C $ Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Mar 19, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project cvector.h comes from c-vector project commit d3f3156373b0587336ac7ee1568755d6cf93dd39 https://github.com/eteran/c-vector uthash.h comes from uthash project commit bf15263081be6229be31addd48566df93921cb46 https://github.com/troydhanson/uthash This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -c a.out 2024-Mar-14 11:47:18 INFO execute command: a.out(pid 256995) [2024-03-14 12:38:36] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(39518) iovisor#1 0x00564a94cc1250 baz+0x1c iovisor#2 0x00564a94cc12d7 main+0x73 iovisor#3 0x007faf6f029d90 [unknown] [2024-03-14 12:38:46] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(39518) iovisor#1 0x00564a94cc1250 baz+0x1c iovisor#2 0x00564a94cc12d7 main+0x73 iovisor#3 0x007faf6f029d90 [unknown] ^C $ Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Mar 20, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project cvector.h comes from c-vector project commit d3f3156373b0587336ac7ee1568755d6cf93dd39 https://github.com/eteran/c-vector uthash.h comes from uthash project commit bf15263081be6229be31addd48566df93921cb46 https://github.com/troydhanson/uthash This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -c a.out 2024-Mar-14 11:47:18 INFO execute command: a.out(pid 256995) [2024-03-14 12:38:36] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(39518) iovisor#1 0x00564a94cc1250 baz+0x1c iovisor#2 0x00564a94cc12d7 main+0x73 iovisor#3 0x007faf6f029d90 [unknown] [2024-03-14 12:38:46] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(39518) iovisor#1 0x00564a94cc1250 baz+0x1c iovisor#2 0x00564a94cc12d7 main+0x73 iovisor#3 0x007faf6f029d90 [unknown] ^C $ Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
May 2, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report doublefree error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute the command and detect doublefree -p, --pid=PID Detect doublefree on the specified process -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat test.cpp #include <chrono> #include <thread> void bar(int* a) { delete a; } int* foo() { return new int; } int main() { std::this_thread::sleep_for(std::chrono::seconds(1)); auto a = foo(); bar(a); bar(a); } $ g++ test.cpp $ sudo ./doublefree -c a.out 2024-May-02 14:30:54 INFO Execute command: a.out(pid 70054) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x007148a02ae98c _Znwm+0x1c (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30+0xae98c) iovisor#2 0x0056166a14924c main+0x46 (/home/bojun/doublefree/libbpf-tools/a.out+0x124c) iovisor#3 0x0071489fe29d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) First deallocation: iovisor#1 0x0071489fea53e0 free+0x0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x0056166a14925c main+0x56 (/home/bojun/doublefree/libbpf-tools/a.out+0x125c) iovisor#3 0x0071489fe29d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) Second deallocation: iovisor#1 0x0071489fea53e0 free+0x0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x0056166a149268 main+0x62 (/home/bojun/doublefree/libbpf-tools/a.out+0x1268) iovisor#3 0x0071489fe29d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
May 15, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report doublefree error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute the command and detect doublefree -p, --pid=PID Detect doublefree on the specified process -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(10); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ sudo ./doublefree -c a.out 2024-May-15 22:30:24 INFO Execute command: a.out(pid 99584) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x00564d1455819b foo+0x12 (/home/bojun/doublefree/libbpf-tools/a.out+0x119b) iovisor#2 0x00564d145581e3 main+0x27 (/home/bojun/doublefree/libbpf-tools/a.out+0x11e3) iovisor#3 0x0070c4e9429d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) First deallocation: iovisor#1 0x0070c4e94a53e0 free+0x0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00564d145581fd main+0x41 (/home/bojun/doublefree/libbpf-tools/a.out+0x11fd) iovisor#3 0x0070c4e9429d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) Second deallocation: iovisor#1 0x0070c4e94a53e0 free+0x0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00564d14558213 main+0x57 (/home/bojun/doublefree/libbpf-tools/a.out+0x1213) iovisor#3 0x0070c4e9429d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
May 22, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project cvector.h comes from c-vector project commit d3f3156373b0587336ac7ee1568755d6cf93dd39 https://github.com/eteran/c-vector uthash.h comes from uthash project commit bf15263081be6229be31addd48566df93921cb46 https://github.com/troydhanson/uthash This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
ekyooo
added a commit
to ekyooo/bcc
that referenced
this issue
Jun 5, 2024
…option Add additional information and change format of backtrace - add symbol base offset, dso name, dso base offset - symbol and dso info is included if it's available in target binary - changed format: INDEX ADDR [SYMBOL+OFFSET] (MODULE+OFFSET) before: # ./capable -UK TIME UID PID COMM CAP NAME AUDIT VER DICT 01:59:17 0 730 irqbalance 21 CAP_SYS_ADMIN 0 deny cap_vm_enough_memory security_vm_enough_memory_mm mmap_region do_mmap vm_mmap_pgoff do_syscall_64 entry_SYSCALL_64_after_hwframe mmap64 - irqbalance (730) After: # ./capable -UKv TIME UID PID COMM CAP NAME AUDIT VERDICT 01:56:37 0 730 irqbalance 21 CAP_SYS_ADMIN 0 deny #0 0xffffffff81447dc6 cap_vm_enough_memory+0x26 iovisor#1 0xffffffff8144a94f security_vm_enough_memory_mm+0x2f iovisor#2 0xffffffff812576e3 mmap_region+0x103 iovisor#3 0xffffffff8125837e do_mmap+0x3de iovisor#4 0xffffffff8122c41c vm_mmap_pgoff+0xdc iovisor#5 0xffffffff81dc3be0 do_syscall_64+0x50 iovisor#6 0xffffffff81e0011b entry_SYSCALL_64_after_hwframe+0x63 iovisor#7 0x00007f3036e9e9ca mmap64+0xa (/lib/x86_64-linux-gnu/libc-2.19.so+0xf49ca) - irqbalance (730)
yonghong-song
pushed a commit
that referenced
this issue
Jun 16, 2024
…option Add additional information and change format of backtrace - add symbol base offset, dso name, dso base offset - symbol and dso info is included if it's available in target binary - changed format: INDEX ADDR [SYMBOL+OFFSET] (MODULE+OFFSET) before: # ./capable -UK TIME UID PID COMM CAP NAME AUDIT VER DICT 01:59:17 0 730 irqbalance 21 CAP_SYS_ADMIN 0 deny cap_vm_enough_memory security_vm_enough_memory_mm mmap_region do_mmap vm_mmap_pgoff do_syscall_64 entry_SYSCALL_64_after_hwframe mmap64 - irqbalance (730) After: # ./capable -UKv TIME UID PID COMM CAP NAME AUDIT VERDICT 01:56:37 0 730 irqbalance 21 CAP_SYS_ADMIN 0 deny #0 0xffffffff81447dc6 cap_vm_enough_memory+0x26 #1 0xffffffff8144a94f security_vm_enough_memory_mm+0x2f #2 0xffffffff812576e3 mmap_region+0x103 #3 0xffffffff8125837e do_mmap+0x3de #4 0xffffffff8122c41c vm_mmap_pgoff+0xdc #5 0xffffffff81dc3be0 do_syscall_64+0x50 #6 0xffffffff81e0011b entry_SYSCALL_64_after_hwframe+0x63 #7 0x00007f3036e9e9ca mmap64+0xa (/lib/x86_64-linux-gnu/libc-2.19.so+0xf49ca) - irqbalance (730)
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Jul 31, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project cvector.h comes from c-vector project commit d3f3156373b0587336ac7ee1568755d6cf93dd39 https://github.com/eteran/c-vector uthash.h comes from uthash project commit bf15263081be6229be31addd48566df93921cb46 https://github.com/troydhanson/uthash This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Jul 31, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Jul 31, 2024
Add doublefree tool to detect double free. It could detect user level double free error currently and can be expanded to detect kernel level double free error. Followings are the usage and example. Usage: $ ./doublefree -h Usage: doublefree [OPTION...] Detect and report doublefree error. -c or -p is a mandatory option EXAMPLES: doublefree -p 1234 # Detect doublefree on process id 1234 doublefree -c a.out # Detect doublefree on a.out doublefree -c 'a.out arg' # Detect doublefree on a.out with argument -c, --command=COMMAND Execute the command and detect doublefree -p, --pid=PID Detect doublefree on the specified process -v, --verbose Verbose debug output -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Example: $ cat doublefree_generator.c #include <unistd.h> #include <stdlib.h> int* foo() { return (int*)malloc(sizeof(int)); } void bar(int* p) { free(p); } int main(int argc, char* argv[]) { sleep(10); int *val = foo(); *val = 33; bar(val); *val = 84; bar(val); return 0; } $ gcc doublefree_generator.c $ sudo ./doublefree -c a.out 2024-May-15 22:30:24 INFO Execute command: a.out(pid 99584) Tracing doublefree... Hit Ctrl-C to stop free(): double free detected in tcache 2 Allocation: iovisor#1 0x00564d1455819b foo+0x12 (/home/bojun/doublefree/libbpf-tools/a.out+0x119b) iovisor#2 0x00564d145581e3 main+0x27 (/home/bojun/doublefree/libbpf-tools/a.out+0x11e3) iovisor#3 0x0070c4e9429d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) First deallocation: iovisor#1 0x0070c4e94a53e0 free+0x0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00564d145581fd main+0x41 (/home/bojun/doublefree/libbpf-tools/a.out+0x11fd) iovisor#3 0x0070c4e9429d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90) Second deallocation: iovisor#1 0x0070c4e94a53e0 free+0x0 (/usr/lib/x86_64-linux-gnu/libc.so.6+0xa53e0) iovisor#2 0x00564d14558213 main+0x57 (/home/bojun/doublefree/libbpf-tools/a.out+0x1213) iovisor#3 0x0070c4e9429d90 [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
CrackerCat
pushed a commit
to CrackerCat/bcc
that referenced
this issue
Jul 31, 2024
Fixing issue iovisor#1515. Currently, each usdt probe (provider, probe_name) can only have locations from the single binary. It is possible that USDT probes are defined in a header file which eventually causes the same usdt probe having locations in several different binary/shared_objects. In such cases, we are not able to attach the same bpf program to all these locations. This patch addresses this issue by defining each location to be `bin_path + addr_offset` vs. previous `addr_offset` only. This way, each internal Probe class can represent all locations for the same (provider, probe_name) pair. The `tplist.py` output is re-organized with the (provider, probe_name) in the top level like below: ``` ... rtld:lll_futex_wake [sema 0x0] location iovisor#1 /usr/lib64/ld-2.17.so 0xaac8 argument iovisor#1 8 unsigned bytes @ di argument iovisor#2 4 signed bytes @ 1 argument iovisor#3 4 signed bytes @ 0 location iovisor#2 /usr/lib64/ld-2.17.so 0xe9b9 argument iovisor#1 8 unsigned bytes @ di argument iovisor#2 4 signed bytes @ 1 argument iovisor#3 4 signed bytes @ 0 location iovisor#3 /usr/lib64/ld-2.17.so 0xef3b argument iovisor#1 8 unsigned bytes @ di argument iovisor#2 4 signed bytes @ 1 argument iovisor#3 4 signed bytes @ 0 ... ``` Tested with the following commands ``` tplist.py trace.py -p <pid> 'u::probe "arg1 = %d", arg1' trace.py u:<binary_path>:probe "arg1 = %d", arg1' argdist.py -p <pid> 'u::probe():s64:arg1' argdist.py -C 'u:<binary_path>:probe():s64:arg1' funccount.py -p <pid> 'u:<binary_path>:probe' funccount.py 'u:<binary_path>:probe' ``` Signed-off-by: Yonghong Song <[email protected]>
CrackerCat
pushed a commit
to CrackerCat/bcc
that referenced
this issue
Jul 31, 2024
With latest llvm12 trunk, we got two compilation bugs. Bug iovisor#1: /home/yhs/work/bcc/src/cc/frontends/clang/b_frontend_action.cc: In member function ‘void ebpf::BFrontendAction::DoMiscWorkAround()’: /home/yhs/work/bcc/src/cc/frontends/clang/b_frontend_action.cc:1706:31: error: ‘class clang::SourceManage’ has no member named ‘getBuffer’; did you mean ‘getBufferData’? rewriter_->getSourceMgr().getBuffer(rewriter_->getSourceMgr().getMainFileID())->getBufferSize(), ^~~~~~~~~ getBufferData This is due to upstream change https://reviews.llvm.org/D89394. To fix, follow upstream examples in https://reviews.llvm.org/D89394. Bug iovisor#2: /home/yhs/work/bcc/src/cc/bpf_module.cc: In member function ‘int ebpf::BPFModule::finalize()’: /home/yhs/work/bcc/src/cc/bpf_module.cc:470:11: error: ‘class llvm::EngineBuilder’ has no member named ‘setUseOrcMCJITReplacement’ builder.setUseOrcMCJITReplacement(false); ^~~~~~~~~~~~~~~~~~~~~~~~~ This is due to upstream llvm/llvm-project@6154c41 It seems builder.setUseOrcMCJITReplacement() is not needed any more. So just remove it from bcc. Signed-off-by: Yonghong Song <[email protected]>
CrackerCat
pushed a commit
to CrackerCat/bcc
that referenced
this issue
Jul 31, 2024
Currently, hardirqs use tid as key to store information while tracepoint irq_handler_entry. It works fine if irq is triggered while normal task running, but there is a chance causing overwrite issue while irq is triggered while idle task (a.k.a swapper/x, tid=0) running on multi-core system. Let's say there are two irq event trigger simultaneously on both CPU core, irq A @ core #0, irq B @ core iovisor#1, and system load is pretty light, so BPF program will get tid=0 since current task is swapper/x for both cpu core. In this case, the information of first irq event stored in map could be overwritten by incoming second irq event. Use tid and cpu_id together to make sure the key is unique for each event in this corner case. Please check more detail at merge request iovisor#2804, iovisor#3733.
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Aug 1, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Aug 8, 2024
Add leaksanitizer(lsan) feature on libbpf-tools lsan feature originally comes from llvm-project https://github.com/llvm/llvm-project This tool detect and report unreachable memory periodically USAGE: $ ./lsan -h Usage: lsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: lsan -p 1234 # Detect leaks on process id 1234 lsan -c a.out # Detect leaks on a.out lsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./lsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/lsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/lsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/lsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Aug 27, 2024
Add ALSan(Attachable Leak Sanitizer) feature on libbpf-tools ALSan feature originally comes from the llvm-project lsan https://github.com/llvm/llvm-project This tool detect and report unreachable memory periodically USAGE: $ ./alsan -h Usage: alsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: alsan -p 1234 # Detect leaks on process id 1234 alsan -c a.out # Detect leaks on a.out alsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./alsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/alsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/alsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/alsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/alsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/alsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/alsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
Bojun-Seo
added a commit
to Bojun-Seo/bcc
that referenced
this issue
Aug 27, 2024
Add ALSan(Attachable Leak Sanitizer) feature on libbpf-tools ALSan feature originally comes from the llvm-project lsan https://github.com/llvm/llvm-project This tool detect and report unreachable memory periodically USAGE: $ ./alsan -h Usage: alsan [OPTION...] Detect memory leak resulting from unreachable pointers. Either -c or -p is a mandatory option EXAMPLES: alsan -p 1234 # Detect leaks on process id 1234 alsan -c a.out # Detect leaks on a.out alsan -c 'a.out arg' # Detect leaks on a.out with argument -c, --command=COMMAND Execute and detect memory leak on the specified command -i, --interval=INTERVAL Set interval in second to detect leak -p, --pid=PID Detect memory leak on the specified process -s, --suppressions=SUPPRESSIONS Suppressions file name -T, --top=TOP Report only specified amount of backtraces -v, --verbose Verbose debug output -w, --stop-the-world Stop the target process during tracing -?, --help Give this help list --usage Give a short usage message -V, --version Print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to https://github.com/iovisor/bcc/tree/master/libbpf-tools. Report example: $ sudo ./alsan -p 28346 [2024-05-22 14:44:58] Print leaks: 44 bytes direct leak found in 1 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/alsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/alsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/alsan/libbpf-tools/a.out+0x1105) [2024-05-22 14:45:08] Print leaks: 132 bytes direct leak found in 3 allocations from stack id(57214) iovisor#1 0x00583bca1b2250 baz+0x1c (/home/bojun/alsan/libbpf-tools/a.out+0x1250) iovisor#2 0x00583bca1b22d7 main+0x73 (/home/bojun/alsan/libbpf-tools/a.out+0x12d7) iovisor#3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca) iovisor#4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b) iovisor#5 0x00583bca1b2105 _start+0x25 (/home/bojun/alsan/libbpf-tools/a.out+0x1105) Source code of test program: $ cat leak_test.c #include <stdlib.h> #include <unistd.h> int *arr[10000]; int *foo(size_t size) { int *tmp = malloc(size); *tmp = 99; return tmp; } int *bar(size_t nmemb, size_t size) { int *tmp = calloc(nmemb, size); *tmp = 22; return tmp; } int *baz(size_t size) { int *tmp = valloc(size); *tmp = 11; return tmp; } int main(int argc, char* argv[]) { int *a; int i = 0; while (1) { a = foo(4); arr[i++] = a; a = bar(4, 4); free(a); a = baz(44); sleep(5); } return 0; }
dkruces
pushed a commit
to dkruces/bcc
that referenced
this issue
Nov 28, 2024
…option Add additional information and change format of backtrace - add symbol base offset, dso name, dso base offset - symbol and dso info is included if it's available in target binary - changed format: INDEX ADDR [SYMBOL+OFFSET] (MODULE+OFFSET) before: # ./capable -UK TIME UID PID COMM CAP NAME AUDIT VER DICT 01:59:17 0 730 irqbalance 21 CAP_SYS_ADMIN 0 deny cap_vm_enough_memory security_vm_enough_memory_mm mmap_region do_mmap vm_mmap_pgoff do_syscall_64 entry_SYSCALL_64_after_hwframe mmap64 - irqbalance (730) After: # ./capable -UKv TIME UID PID COMM CAP NAME AUDIT VERDICT 01:56:37 0 730 irqbalance 21 CAP_SYS_ADMIN 0 deny #0 0xffffffff81447dc6 cap_vm_enough_memory+0x26 iovisor#1 0xffffffff8144a94f security_vm_enough_memory_mm+0x2f iovisor#2 0xffffffff812576e3 mmap_region+0x103 iovisor#3 0xffffffff8125837e do_mmap+0x3de iovisor#4 0xffffffff8122c41c vm_mmap_pgoff+0xdc iovisor#5 0xffffffff81dc3be0 do_syscall_64+0x50 iovisor#6 0xffffffff81e0011b entry_SYSCALL_64_after_hwframe+0x63 iovisor#7 0x00007f3036e9e9ca mmap64+0xa (/lib/x86_64-linux-gnu/libc-2.19.so+0xf49ca) - irqbalance (730)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following is a buggy b-language program.
plumgrid@yhs-plumgrid:~/iovisor/bcc/tests/jit$ cat bpfdev1.b
packed "false"
// hash
struct FwdKey {
u32 dip:32;
};
struct FwdLeaf {
u32 ifindex:32;
};
Table<FwdKey, FwdLeaf, FIXED_MATCH, NONE> fwd_map(1);
// array
struct ConfigKey {
u32 index:32;
};
struct ConfigLeaf {
u32 bpfdev_ip:32;
u32 slave_ip:32;
};
Table<ConfigKey, ConfigLeaf, INDEXED, NONE> config_map(1);
// hash
struct MacaddrKey {
u32 ip:32;
};
struct MacaddrLeaf {
u64 mac:48;
};
Table<MacaddrKey, MacaddrLeaf, FIXED_MATCH, AUTO> macaddr_map(11);
// hash
struct SlaveKey {
u32 slave_ip:32;
};
struct SlaveLeaf {
u32 slave_ifindex:32;
};
Table<SlaveKey, SlaveLeaf, FIXED_MATCH, NONE> slave_map(10);
u32 main(struct proto::skbuff *skb) {
u32 ret:32 = 0xffffffff;
goto proto::ethernet;
state proto::ethernet {
}
state proto::dot1q {
}
if (skb.pkt_type) {
state proto::arp {
if $arp.oper != 1 {
return 0;
}
macaddr_map[$arp.spa] = $arp.sha;
}
state proto::ip {
}
state proto::udp {
if $udp.dport != 5000 {
return 0;
}
FwdKey fwd_key = {.dip = $ip.dst};
FwdLeaf *fwd_idx_p = fwd_map[$ip.dst];
if (fwd_idx_p) {
return fwd_idx_p->fwd_idx;
} else {
return 0;
}
}
} else {
state proto::ip {
}
}
state EOP {
return ret;
}
}
plumgrid@yhs-plumgrid:~/iovisor/bcc/tests/jit$
The compiler error message like the below:
Checking test dependency graph end
test 5
Start 5: py_bpfdev1
5: Test command: /home/plumgrid/iovisor/bcc/build/tests/wrapper.sh "py_bpfdev1" "/home/plumgrid/iovisor/bcc/tests/jit/bpfdev1.py" "namespace"
5: Test timeout computed to be: 9.99988e+06
5: Error: 42.1-5 syntax error
5: In file: bpfdev1.b
5: E
It does not provide sufficient information about where the problem occurs.
Maybe 42.1-5 indicates something, but the message should be better communicated.
The text was updated successfully, but these errors were encountered: