libbpf-tools: Add new feature ALSan by Bojun-Seo · Pull Request #4120 · iovisor/bcc

Bojun-Seo · 2022-07-19T07:55:52Z

Add ALSan(Attachable Leak Sanitizer) feature on libbpf-tools
ALSan feature originally comes from the llvm-project lsan
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:

$ ./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)
        #1 0x00583bca1b2250 baz+0x1c (/home/bojun/alsan/libbpf-tools/a.out+0x1250)
        #2 0x00583bca1b22d7 main+0x73 (/home/bojun/alsan/libbpf-tools/a.out+0x12d7)
        #3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca)
        #4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b)
        #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)
        #1 0x00583bca1b2250 baz+0x1c (/home/bojun/alsan/libbpf-tools/a.out+0x1250)
        #2 0x00583bca1b22d7 main+0x73 (/home/bojun/alsan/libbpf-tools/a.out+0x12d7)
        #3 0x007470c7c2a1ca [unknown] (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca)
        #4 0x007470c7c2a28b __libc_start_main+0x8b (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b)
        #5 0x00583bca1b2105 _start+0x25 (/home/bojun/alsan/libbpf-tools/a.out+0x1105)

^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;
}

chenhengqi · 2022-07-19T11:46:04Z

There is a similar PR in #3828 .

Bojun-Seo · 2022-07-20T00:20:41Z

@chenhengqi, well, lsan is pretty different from memleak.
memleak is to keep tracking currently allocated heap memory,
where lsan is to report dangling pointers within "currently allocated heap memory" like llvm-project leak sanitizer

chenhengqi · 2022-07-20T00:59:29Z

Fine, could you describe how does it work ?

Bojun-Seo · 2022-07-20T01:54:23Z

Followings are the way it work.(Refer to this document https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument)
lsan hooks memory allocating functions(malloc, calloc, free.. etc).
It considers memory space as direct graph.(Consider every value as a pointer)
Set hooked node as "unreachable", before it starts following steps.(and repeat periodically)
One, it traverses from the root set and mark reachable node as "reachable"
Two, it traverses again from the hooked set and marks reachable node as "indirect" if it is "unreachable" node.
Three, sort and report "unreachable" node as direct leak and "indirect" node as indirect leak.

About root set:
Root set denotes these things.
global variables, stacks of running threads, general-purpose registers of running threads, ELF thread-local storage and POSIX thread-specific data.
Original lsan is a library, so it can use API to get this information.
BPF lsan is an independent process, so it use ptrace api to get general-purpose registers, and read /proc/pid/maps to get others.

Indirect leak means not reachable allocation node from the root but can be reachable from some unreachable block.
Direct leak means not reachable allocation node from the root and not indirect leak.

Bojun-Seo · 2022-08-16T03:30:39Z

The memory leak problem is an old problem and has not yet been conquered but very important. To solve memory leak problem, various methods have been tried and the best way is using a tool so far. There are two types of tools: static tools and dynamic tools.
In case of static tools, operation time and detection capability are trade off. Theoretically, almost infinite amount of time is required to detect all memory leaks using a static analysis tool. So static tool usually used to detect quite easy memory leaks because of time limitations.
In case of dynamic tools, there are two famous dynamic memory leak detecting tools: Valgrind and llvm-project LeakSanitizer.
These tools are good but have limitations. Valgrind performance degradation is about 10-50 times. It is difficult to use even in a desktop environment, and it is virtually impossible to use in an embedded system. llvm-project LeakSanitizer has little performance degradation, but not easy to use. And both tool require to restart the target program and can get report at termination of the target process.
I suggest bcc lsan(this PR) to solve these problems. It has little performance degradation, is easy to use, can be applied immediately to a running process, and can get report without target process termination.
For example, imagine if you developed a new service(daemon), which has no scenario to be quit. Somehow you found some weird memory increasement on the service. How can you debug it? To use llvm-project LeakSanitizer or Valgrind, you need to make exit routine on your program, regenerate the issue and rerun the program. Making good exit routine is quite hard but let's consider you did it well. But what if it takes 3 days to regenerate this issue? Maybe you need to stop the factory 3 days.
bcc lsan will reduce and remove these kind of problems. Because it can be applied immediately and generate report in the middle of the target process execution.

eiffel-fl

Hi.

First of all, I would like to thank you for your contribution, it seems really cool.
I have some comments regarding the eBPF code.
I will take a look later at the C userland code (even though I am not 100% I will be able to understand the logic).

Best regards.

eiffel-fl

Hi.

This time, I took a look at the userspace code.
I am not 100% sure I understand the whole code particularly all the hash maps you need but it worked!
I also share your opinion about being able to quickly spot memory leak at runtime while not slowing the application (contrary to valgrind even though I really like this tool).

I tried to run it and I had to modify the following:

diff --git a/libbpf-tools/lsan.c b/libbpf-tools/lsan.c
index dcb3862e..1cd9538b 100644
--- a/libbpf-tools/lsan.c
+++ b/libbpf-tools/lsan.c
@@ -358,11 +358,11 @@ static int get_libc_path(char *path)
                        continue;
 
                file_name = strrchr(buf, '/') + 1;
-#ifdef __aarch64__
+// #ifdef __aarch64__
                if (sscanf(file_name, "libc-%f.so", &version) == 1) {
-#else
-               if (sscanf(file_name, "libc.so.%f", &version) == 1) {
-#endif
+// #else
+//             if (sscanf(file_name, "libc.so.%f", &version) == 1) {
+// #endif
                        memcpy(path, buf, strlen(buf));
                        fclose(f);
                        return 0;

Indeed, on my system, I have:

francis@pwmachine:~/Codes/kinvolk/bcc/libbpf-tools$ lsb_release -a                                                                                  
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.5 LTS
Release:        20.04
Codename:       focal
francis@pwmachine:~/Codes/kinvolk/bcc/libbpf-tools$ uname -a                                                                                        
Linux pwmachine 5.15.0-48-generic #54~20.04.1-Ubuntu SMP Thu Sep 1 16:17:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
francis@pwmachine:~/Codes/kinvolk/bcc/libbpf-tools$ ls -l /usr/lib/x86_64-linux-gnu/libc.so.6                                                       
lrwxrwxrwx 1 root root 12 avril  7 03:24 /usr/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so

After this modification, I was able to get the same output as you (plus the value 99 printed by a.out).

Best regards.

chenhengqi · 2022-10-17T12:33:42Z

Sorry for the long delay, I will try finishing this review this week.

chenhengqi · 2022-10-20T15:21:45Z

Ping me if this PR is ready for review.

Bojun-Seo · 2022-10-24T06:23:26Z

@chenhengqi
This PR is ready to be reviewed

eiffel-fl

I tested it again and it works fine:

$ sudo ./lsan -c /tmp/test -s /tmp/suppr.txt                   (remotes/bojun/lsan) *%
[sudo] Mot de passe de francis : 
Info: Execute child process: /tmp/test
Info: execute command: /tmp/test(pid 94525)
99
99

[2023-11-08 16:15:57] Print leaks:
4 bytes direct leak found in 1 allocations from stack id(41605)
        #1 0x00557fb2fee1bf foo+0x16 (/tmp/test+0x11bf)
        #2 0x00557fb2fee21b main+0x1e (/tmp/test+0x121b)
        #3 0x007f4794629d90 __libc_init_first+0x90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)

99

[2023-11-08 16:16:07] Print leaks:
8 bytes direct leak found in 2 allocations from stack id(41605)
        #1 0x00557fb2fee1bf foo+0x16 (/tmp/test+0x11bf)
        #2 0x00557fb2fee21b main+0x1e (/tmp/test+0x121b)
        #3 0x007f4794629d90 __libc_init_first+0x90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)

99

[2023-11-08 16:16:17] Print leaks:
12 bytes direct leak found in 3 allocations from stack id(41605)
        #1 0x00557fb2fee1bf foo+0x16 (/tmp/test+0x11bf)
        #2 0x00557fb2fee21b main+0x1e (/tmp/test+0x121b)
        #3 0x007f4794629d90 __libc_init_first+0x90 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29d90)

Apart from the two nits I found earlier, it is, for me, ready to go!
Thank you for this cool tool!

Bojun-Seo · 2024-03-14T05:32:48Z

Difference between memleak and lsan
memleak shows the status of memory allocation. In other words, it shows memory allocated but not released.
lsan shows the unreachable memory among allocated memory.

Followings are the test code

#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;
}

memory allocated by foo is saved on arr array. So it is reachable and not deallocated.
memory allocated by bar is deallocated.
memory allocated by baz will become unreachable(as well as not deallocated).

So, memleak reports deallocated allocations. foo and baz

$ sudo ./memleak -c a.out
[sudo] password for bojun:
using default object: libc.so.6
using page size: 4096
tracing kernel: false
child created with pid: 257140
Tracing outstanding memory allocs...  Hit Ctrl-C to end
received go event. executing child command
[14:18:6] Top 2 stacks with outstanding allocations:
88 bytes in 2 allocations from stack
        0 [<000055f3810e1250>] baz+0x1c
        1 [<000055f3810e12d7>] main+0x73
        2 [<00007fbd77829d90>] __libc_init_first+0x90
8 bytes in 2 allocations from stack
        0 [<000055f3810e11e5>] foo+0x1c
        1 [<000055f3810e1288>] main+0x24
        2 [<00007fbd77829d90>] __libc_init_first+0x90
[14:18:11] Top 2 stacks with outstanding allocations:
132 bytes in 3 allocations from stack
        0 [<000055f3810e1250>] baz+0x1c
        1 [<000055f3810e12d7>] main+0x73
        2 [<00007fbd77829d90>] __libc_init_first+0x90
12 bytes in 3 allocations from stack
        0 [<000055f3810e11e5>] foo+0x1c
        1 [<000055f3810e1288>] main+0x24
        2 [<00007fbd77829d90>] __libc_init_first+0x90

^C[14:18:12] Top 2 stacks with outstanding allocations:
132 bytes in 3 allocations from stack
        0 [<000055f3810e1250>] <null sym>
        1 [<000055f3810e12d7>] <null sym>
        2 [<00007fbd77829d90>] <null sym>
12 bytes in 3 allocations from stack
        0 [<000055f3810e11e5>] <null sym>
        1 [<000055f3810e1288>] <null sym>
        2 [<00007fbd77829d90>] <null sym>
reaped child process
done

lsan reports only unreachable allocations. baz.

$ sudo ./lsan -c a.out
2024-Mar-14 11:47:18 INFO execute command: a.out(pid 257157)

[2024-03-14 14:26:51] Print leaks:
44 bytes direct leak found in 1 allocations from stack id(65376)
        #1 0x00559d087a2250 baz+0x1c
        #2 0x00559d087a22d7 main+0x73
        #3 0x007f0b3a629d90 [unknown]


[2024-03-14 14:27:01] Print leaks:
132 bytes direct leak found in 3 allocations from stack id(65376)
        #1 0x00559d087a2250 baz+0x1c
        #2 0x00559d087a22d7 main+0x73
        #3 0x007f0b3a629d90 [unknown]

^C

eiffel-fl

Hi!

I already approved it, so it should be OK.
Reading the code again, I just have one question with regard to avoid having several loops, but I am doubtful this is possible.

Best regards.

eiffel-fl · 2024-03-14T13:50:53Z

+	for_each_tid_ptrace(PTRACE_SEIZE);
+	for_each_tid_ptrace(PTRACE_INTERRUPT);
+	for_each_tid_waitpid();


Would it make sense to have the code inside one loop and doing all these operations inside this loop?
Something like this:

save_roots(); for (i = 0; i < cvector_size(tids); ++i) { ret = ptrace(PTRACE_SEIZE, tids[i], NULL, NULL); if // ... ret = ptrace(PTRACE_INTERRUPT, tids[i], NULL, NULL); if // ... ret = waitpid(tids[i], NULL, __WALL); if // ... } ret = read_table(); if (ret < 0) { p_warn("Failed to read_table, retry after %d seconds", env.interval); for_each_tid_ptrace(PTRACE_DETACH); return 0; } HASH_ITER(hh, allocs, curr, next) { mark_indirectly_leaked_cb(curr->id); collect_leaks_cb(curr->id); } for_each_tid_ptrace(PTRACE_DETACH); report_leaks(syms_cache); return 0;

What do you think?

Yes, it could be possible to have the code inside one loop and doing all ptrace attach, interrupt and waitpid inside the loop, which will mitigate loop overhead.

I think it would be better to factorize it for readability.
However, despite the intention to factorize it for readability, it currently doesn't seem to be very readable.
I think that's why you think it would be better to make one loop.
I'll revise this function to enhance its readability.

Thanks!

I tried to change the code as you suggested, but because of the env.stop_the_world flag, the code became more complicated. This means the current code has better readability in my opinion. So I decided to stick with it. However, your suggestion is very good, and I'll change the code if I find a more readable way.

Thanks!

Bojun-Seo · 2024-07-31T02:26:03Z

I split my whole patch into three parts.

Adding open source cvector.h file
Adding open source uthash.h file
Lsan implementation

Bojun-Seo · 2024-08-01T01:09:47Z

I changed alignment value(loop stride factor) in function scan_range_for_pointers from 1 to WORD_SIZE for performance.

In case of tracing chrome during it is playing Youtube, the overhead was about 179 seconds and now it becomes 22 seconds with this change.(about 8 times faster)

eiffel-fl

Hi!

I have one comment with regard to cvector.h and uthash.h.

Best regards.

Bojun-Seo · 2024-08-27T02:53:37Z

Rebase and change the tool name from lsan to alsan because lsan is a name that is already in use.
This tool is not lsan, so I changed the name to alsan to make it clear.

Bojun-Seo · 2024-09-27T01:51:37Z

There was a talk about this feature in C++ Now conference.

https://youtu.be/9f5hd-8suVE?si=lOli99myFpExgzac

I hope this video helps people understand this patch.

Add submodule c-vector https://github.com/eteran/c-vector This project is header only library project that contains interfaces and implementations of vector container which can be used in C The license of this project is MIT

Add submodule uthash https://github.com/troydhanson/uthash This project is header only library project that contains interfaces and implementations of hash map container which can be used in C The license is written on the top of the file uthash.h

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 requested review from 4ast, brendangregg, davemarchevsky, drzaeus77, goldshtn and yonghong-song as code owners July 19, 2022 07:55

Bojun-Seo changed the title ~~bbpf-tools: Add new feature(leaksanitizer) on BPF CO-RE~~ bpf-tools: Add new feature(leaksanitizer) on BPF CO-RE Jul 19, 2022

Bojun-Seo force-pushed the lsan branch 5 times, most recently from 3473249 to 5b90929 Compare July 19, 2022 08:31

Bojun-Seo force-pushed the lsan branch 2 times, most recently from ef2f5aa to d1b49ec Compare August 2, 2022 06:46

eiffel-fl reviewed Sep 29, 2022

View reviewed changes

Comment thread libbpf-tools/lsan.bpf.c Outdated

Comment thread libbpf-tools/lsan.bpf.c Outdated

Comment thread libbpf-tools/lsan.bpf.c Outdated

eiffel-fl reviewed Oct 3, 2022

View reviewed changes

Bojun-Seo force-pushed the lsan branch from 4181eb4 to 84bb160 Compare October 13, 2022 01:46

chenhengqi reviewed Oct 17, 2022

View reviewed changes

Comment thread libbpf-tools/cvector.h Outdated

Comment thread libbpf-tools/Makefile Outdated

Comment thread libbpf-tools/lsan.h Outdated

Comment thread libbpf-tools/lsan.bpf.c Outdated

Comment thread libbpf-tools/lsan.bpf.c Outdated

Comment thread libbpf-tools/lsan.bpf.c Outdated

Bojun-Seo mentioned this pull request Oct 18, 2022

Add copyright and license on the top of the cvector.h file eteran/c-vector#42

Merged

Bojun-Seo force-pushed the lsan branch 3 times, most recently from a8db792 to bb2970c Compare October 24, 2022 06:13

eiffel-fl approved these changes Nov 8, 2023

View reviewed changes

eiffel-fl reviewed Nov 9, 2023

View reviewed changes

Comment thread libbpf-tools/lsan.c Outdated

Comment thread libbpf-tools/lsan.c Outdated

Bojun-Seo force-pushed the lsan branch 2 times, most recently from 5ebfbd2 to 5badd76 Compare November 27, 2023 06:05

eiffel-fl reviewed Nov 27, 2023

View reviewed changes

Comment thread libbpf-tools/lsan.c Outdated

Bojun-Seo marked this pull request as draft March 2, 2024 00:33

Bojun-Seo force-pushed the lsan branch from 5badd76 to b36c04c Compare March 14, 2024 03:43

Bojun-Seo marked this pull request as ready for review March 14, 2024 03:54

eiffel-fl reviewed Mar 14, 2024

View reviewed changes

Bojun-Seo force-pushed the lsan branch 2 times, most recently from 0b3b594 to 3d87358 Compare March 20, 2024 04:34

Bojun-Seo force-pushed the lsan branch from 3d87358 to 246de2f Compare May 22, 2024 05:48

Bojun-Seo force-pushed the lsan branch 2 times, most recently from 0b2ecc7 to 0d25050 Compare July 31, 2024 02:23

Bojun-Seo force-pushed the lsan branch from 0d25050 to 3a547a8 Compare August 1, 2024 01:05

eiffel-fl reviewed Aug 6, 2024

View reviewed changes

Comment thread libbpf-tools/cvector.h Outdated

Comment thread libbpf-tools/lsan.c

Bojun-Seo force-pushed the lsan branch from 3a547a8 to 00391b7 Compare August 8, 2024 01:58

Bojun-Seo force-pushed the lsan branch from 00391b7 to 44b1dbd Compare August 27, 2024 02:43

Bojun-Seo changed the title ~~libbpf-tools: Add new feature lsan~~ libbpf-tools: Add new feature ALSan Aug 27, 2024

Bojun-Seo force-pushed the lsan branch from 44b1dbd to cedf232 Compare August 27, 2024 02:48

Bojun-Seo added 3 commits April 29, 2026 15:57

libbpf-tools: Add submodule c-vector

0714345

Add submodule c-vector https://github.com/eteran/c-vector This project is header only library project that contains interfaces and implementations of vector container which can be used in C The license of this project is MIT

libbpf-tools: Add submodule uthash

42c8ea6

Add submodule uthash https://github.com/troydhanson/uthash This project is header only library project that contains interfaces and implementations of hash map container which can be used in C The license is written on the top of the file uthash.h

Bojun-Seo force-pushed the lsan branch from cedf232 to 14505a4 Compare April 29, 2026 06:57

Bojun-Seo requested a review from ekyooo as a code owner April 29, 2026 06:57

Conversation

Bojun-Seo commented Jul 19, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chenhengqi commented Jul 19, 2022

Uh oh!

Bojun-Seo commented Jul 20, 2022

Uh oh!

chenhengqi commented Jul 20, 2022

Uh oh!

Bojun-Seo commented Jul 20, 2022

Uh oh!

Bojun-Seo commented Aug 16, 2022

Uh oh!

eiffel-fl left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

eiffel-fl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chenhengqi commented Oct 17, 2022

Uh oh!

chenhengqi commented Oct 20, 2022

Uh oh!

Bojun-Seo commented Oct 24, 2022

Uh oh!

eiffel-fl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Bojun-Seo commented Mar 14, 2024

Uh oh!

eiffel-fl left a comment

Choose a reason for hiding this comment

Uh oh!

eiffel-fl Mar 14, 2024

Choose a reason for hiding this comment

Uh oh!

Bojun-Seo Mar 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Bojun-Seo Aug 1, 2024

Choose a reason for hiding this comment

Uh oh!

Bojun-Seo commented Jul 31, 2024

Uh oh!

Bojun-Seo commented Aug 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eiffel-fl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Bojun-Seo commented Aug 27, 2024

Uh oh!

Bojun-Seo commented Sep 27, 2024

Uh oh!

Reviewers

Bojun-Seo commented Jul 19, 2022 •

edited

Loading

eiffel-fl left a comment •

edited

Loading

Bojun-Seo Mar 18, 2024 •

edited

Loading

Bojun-Seo commented Aug 1, 2024 •

edited

Loading