Skip to content
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

support C-style /* ... */ comment? #3

Closed
yonghong-song opened this issue May 4, 2015 · 1 comment
Closed

support C-style /* ... */ comment? #3

yonghong-song opened this issue May 4, 2015 · 1 comment

Comments

@yonghong-song
Copy link
Collaborator

I am adding arp support in proto.b, and I found /* ... */ is not supported.

......
state ethernet {
switch $ethernet.type {
case 0x0800 {
next proto::ip;
};
case 0x0806 {
next proto::arp;
};
case 0x8100 {
next proto::dot1q;
};
case * {
goto EOP;
};
}
}

/*
// struct arp {
// u32 htype:16
// u32 ptype:16
// u32 hlen:8
// u32 plen:8
// u32 oper:16
// u64 sha:48
// u32 spa:32
// u64 tha:48
// u32 tpa:32
// }

// state arp {
// goto EOP;
// }
*/
.....

If user want to comment out a large portion of code, a single /* ... */ is better than a bunch of //.
What do you think?

@drzaeus77
Copy link
Collaborator

Supported with clang frontend.

drzaeus77 pushed a commit that referenced this issue Feb 18, 2016
update local with changes from master
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]>
oriolarcas pushed a commit to oriolarcas/bcc that referenced this issue Feb 15, 2019
Debugging eBPF programs can be tricky. The clang debug flags are not
supported in all the code-loading branches yet - e.g., only load_prog()
supports BPF_DEBUG or DEBUG_BPF_REGISTER_STATE, but compiling a kprobe
with BPF(...) doesn't.

This built-in disassembler can disassemble and print the BPF code in a
similar syntax than the kernel, whenever and the number of times the
user needs it. The BPF ISA is relatively stable so it doesn't require
much maintenance.

In addition, this parser is agnostic from the original source language
(C, B, Go, etc.), and doesn't depend on a particular compiler.

Example output for trace_pid_start() in biotop:

Disassemble of BPF program trace_pid_start:
   0: (79) r1 = *(u64*)(r1 +112)
   1: (7b) *(u64*)(r10 -8) = r1
   2: (b7) r1 = 0
   3: (63) *(u32*)(r10 -16) = r1
   4: (7b) *(u64*)(r10 -24) = r1
   5: (7b) *(u64*)(r10 -32) = r1
   6: (bf) r1 = r10
   7: (07) r1 += -28
   8: (b7) r2 = 16
   9: (85) call bpf_get_current_comm#16
  10: (67) r0 <<= 32
  11: (77) r0 >>= 32
  12: (55) if r0 != 0 goto +10 <23>
  13: (85) call bpf_get_current_pid_tgid#14
  14: (63) *(u32*)(r10 -32) = r0
  15: (18) r1 = <map at fd iovisor#3>
  17:      (64-bit upper word)
  17: (bf) r2 = r10
  18: (07) r2 += -8
  19: (bf) r3 = r10
  20: (07) r3 += -32
  21: (b7) r4 = 0
  22: (85) call bpf_map_update_elem#2
  23: (b7) r0 = 0
  24: (95) exit

The fields, types and memory layouts of maps can also be printed, which
is something that can be really helpful when dealing with unaligned
accesses or packed vs unpacked structures, and currently not supported
by clang.

For a map with key:

  struct {int a; short b; struct {int c:4; int d:8;};});

and value u64 the example output is:

Layout of BPF type HASH map test_map (ID 0):
  struct {
    [0 +4] int a;
    [4 +2] short b;
    [6 +2] char[2] __pad_2;
    [8 +4] struct {
      int c:4;
      int d:8;
    } __anon0;
  } key;
  unsigned long long value;

The [X +Y] is optional and denotes the offset and the size of each
field. Note that bit-fields and padding fields are shown.
oriolarcas pushed a commit to oriolarcas/bcc that referenced this issue Feb 15, 2019
Debugging eBPF programs can be tricky. The clang debug flags are not
supported in all the code-loading branches yet - e.g., only load_prog()
supports BPF_DEBUG or DEBUG_BPF_REGISTER_STATE, but compiling a kprobe
with BPF(...) doesn't.

This built-in disassembler can disassemble and print the BPF code in a
similar syntax than the kernel, whenever and the number of times the
user needs it. The BPF ISA is relatively stable so it doesn't require
much maintenance.

In addition, this parser is agnostic from the original source language
(C, B, Go, etc.), and doesn't depend on a particular compiler.

Example output for trace_pid_start() in biotop:

Disassemble of BPF program trace_pid_start:
   0: (79) r1 = *(u64*)(r1 +112)
   1: (7b) *(u64*)(r10 -8) = r1
   2: (b7) r1 = 0
   3: (63) *(u32*)(r10 -16) = r1
   4: (7b) *(u64*)(r10 -24) = r1
   5: (7b) *(u64*)(r10 -32) = r1
   6: (bf) r1 = r10
   7: (07) r1 += -28
   8: (b7) r2 = 16
   9: (85) call bpf_get_current_comm#16
  10: (67) r0 <<= 32
  11: (77) r0 >>= 32
  12: (55) if r0 != 0 goto +10 <23>
  13: (85) call bpf_get_current_pid_tgid#14
  14: (63) *(u32*)(r10 -32) = r0
  15: (18) r1 = <map at fd iovisor#3>
  17:      (64-bit upper word)
  17: (bf) r2 = r10
  18: (07) r2 += -8
  19: (bf) r3 = r10
  20: (07) r3 += -32
  21: (b7) r4 = 0
  22: (85) call bpf_map_update_elem#2
  23: (b7) r0 = 0
  24: (95) exit

The fields, types and memory layouts of maps can also be printed, which
is something that can be really helpful when dealing with unaligned
accesses or packed vs unpacked structures, and currently not supported
by clang.

For a map with key:

  struct {int a; short b; struct {int c:4; int d:8;};});

and value u64 the example output is:

Layout of BPF type HASH map test_map (ID 0):
  struct {
    [0 +4] int a;
    [4 +2] short b;
    [6 +2] char[2] __pad_2;
    [8 +4] struct {
      int c:4;
      int d:8;
    } __anon0;
  } key;
  unsigned long long value;

The [X +Y] is optional and denotes the offset and the size of each
field. Note that bit-fields and padding fields are shown.
oriolarcas pushed a commit to oriolarcas/bcc that referenced this issue Feb 15, 2019
Debugging eBPF programs can be tricky. The clang debug flags are not
supported in all the code-loading branches yet - e.g., only load_prog()
supports BPF_DEBUG or DEBUG_BPF_REGISTER_STATE, but compiling a kprobe
with BPF(...) doesn't.

This built-in disassembler can disassemble and print the BPF code in a
similar syntax than the kernel, whenever and the number of times the
user needs it. The BPF ISA is relatively stable so it doesn't require
much maintenance.

In addition, this parser is agnostic from the original source language
(C, B, Go, etc.), and doesn't depend on a particular compiler.

Example output for trace_pid_start() in biotop:

Disassemble of BPF program trace_pid_start:
   0: (79) r1 = *(u64*)(r1 +112)
   1: (7b) *(u64*)(r10 -8) = r1
   2: (b7) r1 = 0
   3: (63) *(u32*)(r10 -16) = r1
   4: (7b) *(u64*)(r10 -24) = r1
   5: (7b) *(u64*)(r10 -32) = r1
   6: (bf) r1 = r10
   7: (07) r1 += -28
   8: (b7) r2 = 16
   9: (85) call bpf_get_current_comm#16
  10: (67) r0 <<= 32
  11: (77) r0 >>= 32
  12: (55) if r0 != 0 goto +10 <23>
  13: (85) call bpf_get_current_pid_tgid#14
  14: (63) *(u32*)(r10 -32) = r0
  15: (18) r1 = <map at fd iovisor#3>
  17:      (64-bit upper word)
  17: (bf) r2 = r10
  18: (07) r2 += -8
  19: (bf) r3 = r10
  20: (07) r3 += -32
  21: (b7) r4 = 0
  22: (85) call bpf_map_update_elem#2
  23: (b7) r0 = 0
  24: (95) exit

The fields, types and memory layouts of maps can also be printed, which
is something that can be really helpful when dealing with unaligned
accesses or packed vs unpacked structures, and currently not supported
by clang.

For a map with key:

  struct {int a; short b; struct {int c:4; int d:8;};});

and value u64 the example output is:

Layout of BPF type HASH map test_map (ID 0):
  struct {
    [0 +4] int a;
    [4 +2] short b;
    [6 +2] char[2] __pad_2;
    [8 +4] struct {
      int c:4;
      int d:8;
    } __anon0;
  } key;
  unsigned long long value;

The [X +Y] is optional and denotes the offset and the size of each
field. Note that bit-fields and padding fields are shown.
yonghong-song pushed a commit that referenced this issue Feb 22, 2019
* Python BPF disassembler and map layout parser

Debugging eBPF programs can be tricky. The clang debug flags are not
supported in all the code-loading branches yet - e.g., only load_prog()
supports BPF_DEBUG or DEBUG_BPF_REGISTER_STATE, but compiling a kprobe
with BPF(...) doesn't.

This built-in disassembler can disassemble and print the BPF code in a
similar syntax than the kernel, whenever and the number of times the
user needs it. The BPF ISA is relatively stable so it doesn't require
much maintenance.

In addition, this parser is agnostic from the original source language
(C, B, Go, etc.), and doesn't depend on a particular compiler.

Example output for trace_pid_start() in biotop:

Disassemble of BPF program trace_pid_start:
   0: (79) r1 = *(u64*)(r1 +112)
   1: (7b) *(u64*)(r10 -8) = r1
   2: (b7) r1 = 0
   3: (63) *(u32*)(r10 -16) = r1
   4: (7b) *(u64*)(r10 -24) = r1
   5: (7b) *(u64*)(r10 -32) = r1
   6: (bf) r1 = r10
   7: (07) r1 += -28
   8: (b7) r2 = 16
   9: (85) call bpf_get_current_comm#16
  10: (67) r0 <<= 32
  11: (77) r0 >>= 32
  12: (55) if r0 != 0 goto +10 <23>
  13: (85) call bpf_get_current_pid_tgid#14
  14: (63) *(u32*)(r10 -32) = r0
  15: (18) r1 = <map at fd #3>
  17:      (64-bit upper word)
  17: (bf) r2 = r10
  18: (07) r2 += -8
  19: (bf) r3 = r10
  20: (07) r3 += -32
  21: (b7) r4 = 0
  22: (85) call bpf_map_update_elem#2
  23: (b7) r0 = 0
  24: (95) exit

The fields, types and memory layouts of maps can also be printed, which
is something that can be really helpful when dealing with unaligned
accesses or packed vs unpacked structures, and currently not supported
by clang.

For a map with key:

  struct {int a; short b; struct {int c:4; int d:8;};});

and value u64 the example output is:

Layout of BPF type HASH map test_map (ID 0):
  struct {
    [0 +4] int a;
    [4 +2] short b;
    [6 +2] char[2] __pad_2;
    [8 +4] struct {
      int c:4;
      int d:8;
    } __anon0;
  } key;
  unsigned long long value;

The [X +Y] is optional and denotes the offset and the size of each
field. Note that bit-fields and padding fields are shown.

Signed-off-by: Oriol Arcas <[email protected]>
arighi pushed a commit to arighi/bcc that referenced this issue Mar 21, 2019
* Python BPF disassembler and map layout parser

Debugging eBPF programs can be tricky. The clang debug flags are not
supported in all the code-loading branches yet - e.g., only load_prog()
supports BPF_DEBUG or DEBUG_BPF_REGISTER_STATE, but compiling a kprobe
with BPF(...) doesn't.

This built-in disassembler can disassemble and print the BPF code in a
similar syntax than the kernel, whenever and the number of times the
user needs it. The BPF ISA is relatively stable so it doesn't require
much maintenance.

In addition, this parser is agnostic from the original source language
(C, B, Go, etc.), and doesn't depend on a particular compiler.

Example output for trace_pid_start() in biotop:

Disassemble of BPF program trace_pid_start:
   0: (79) r1 = *(u64*)(r1 +112)
   1: (7b) *(u64*)(r10 -8) = r1
   2: (b7) r1 = 0
   3: (63) *(u32*)(r10 -16) = r1
   4: (7b) *(u64*)(r10 -24) = r1
   5: (7b) *(u64*)(r10 -32) = r1
   6: (bf) r1 = r10
   7: (07) r1 += -28
   8: (b7) r2 = 16
   9: (85) call bpf_get_current_comm#16
  10: (67) r0 <<= 32
  11: (77) r0 >>= 32
  12: (55) if r0 != 0 goto +10 <23>
  13: (85) call bpf_get_current_pid_tgid#14
  14: (63) *(u32*)(r10 -32) = r0
  15: (18) r1 = <map at fd iovisor#3>
  17:      (64-bit upper word)
  17: (bf) r2 = r10
  18: (07) r2 += -8
  19: (bf) r3 = r10
  20: (07) r3 += -32
  21: (b7) r4 = 0
  22: (85) call bpf_map_update_elem#2
  23: (b7) r0 = 0
  24: (95) exit

The fields, types and memory layouts of maps can also be printed, which
is something that can be really helpful when dealing with unaligned
accesses or packed vs unpacked structures, and currently not supported
by clang.

For a map with key:

  struct {int a; short b; struct {int c:4; int d:8;};});

and value u64 the example output is:

Layout of BPF type HASH map test_map (ID 0):
  struct {
    [0 +4] int a;
    [4 +2] short b;
    [6 +2] char[2] __pad_2;
    [8 +4] struct {
      int c:4;
      int d:8;
    } __anon0;
  } key;
  unsigned long long value;

The [X +Y] is optional and denotes the offset and the size of each
field. Note that bit-fields and padding fields are shown.

Signed-off-by: Oriol Arcas <[email protected]>
palexster referenced this issue in palexster/bcc Jul 7, 2019
* Python BPF disassembler and map layout parser

Debugging eBPF programs can be tricky. The clang debug flags are not
supported in all the code-loading branches yet - e.g., only load_prog()
supports BPF_DEBUG or DEBUG_BPF_REGISTER_STATE, but compiling a kprobe
with BPF(...) doesn't.

This built-in disassembler can disassemble and print the BPF code in a
similar syntax than the kernel, whenever and the number of times the
user needs it. The BPF ISA is relatively stable so it doesn't require
much maintenance.

In addition, this parser is agnostic from the original source language
(C, B, Go, etc.), and doesn't depend on a particular compiler.

Example output for trace_pid_start() in biotop:

Disassemble of BPF program trace_pid_start:
   0: (79) r1 = *(u64*)(r1 +112)
   1: (7b) *(u64*)(r10 -8) = r1
   2: (b7) r1 = 0
   3: (63) *(u32*)(r10 -16) = r1
   4: (7b) *(u64*)(r10 -24) = r1
   5: (7b) *(u64*)(r10 -32) = r1
   6: (bf) r1 = r10
   7: (07) r1 += -28
   8: (b7) r2 = 16
   9: (85) call bpf_get_current_comm#16
  10: (67) r0 <<= 32
  11: (77) r0 >>= 32
  12: (55) if r0 != 0 goto +10 <23>
  13: (85) call bpf_get_current_pid_tgid#14
  14: (63) *(u32*)(r10 -32) = r0
  15: (18) r1 = <map at fd polycube-network#3>
  17:      (64-bit upper word)
  17: (bf) r2 = r10
  18: (07) r2 += -8
  19: (bf) r3 = r10
  20: (07) r3 += -32
  21: (b7) r4 = 0
  22: (85) call bpf_map_update_elem#2
  23: (b7) r0 = 0
  24: (95) exit

The fields, types and memory layouts of maps can also be printed, which
is something that can be really helpful when dealing with unaligned
accesses or packed vs unpacked structures, and currently not supported
by clang.

For a map with key:

  struct {int a; short b; struct {int c:4; int d:8;};});

and value u64 the example output is:

Layout of BPF type HASH map test_map (ID 0):
  struct {
    [0 +4] int a;
    [4 +2] short b;
    [6 +2] char[2] __pad_2;
    [8 +4] struct {
      int c:4;
      int d:8;
    } __anon0;
  } key;
  unsigned long long value;

The [X +Y] is optional and denotes the offset and the size of each
field. Note that bit-fields and padding fields are shown.

Signed-off-by: Oriol Arcas <[email protected]>
sebymiano pushed a commit to sebymiano/bcc that referenced this issue Feb 20, 2020
New method getTableDescription() in BPBTableBase class
ekyooo added a commit to ekyooo/bcc that referenced this issue Feb 20, 2022
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)

Print backtrace of ip if it failed to get syms.

Before:
  # profile -d
      psiginfo
      vscanf
      __snprintf_chk
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      sd_event_exit
      sd_event_dispatch
      sd_event_run
      [unknown]
      __libc_start_main
      [unknown]
      -                systemd-journal (204)
          1

      xas_load
      xas_find
      filemap_map_pages
      __handle_mm_fault
      handle_mm_fault
      do_page_fault
      do_translation_fault
      do_mem_abort
      do_el0_ia_bp_hardening
      el0_ia
      xas_load
      --
  failed to get syms
      -                PmLogCtl (138757)
        1

After:
  # profile -d
      #0  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      iovisor#1  0xffffffc01009a93c el0_svc_handler+0x34
      iovisor#2  0xffffffc010084a08 el0_svc+0x8
      iovisor#3  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      --
      iovisor#4  0x0000007fa0bffd14 clock_nanosleep+0x94 (/usr/lib/libc-2.31.so+0x9ed14)
      iovisor#5  0x0000007fa0c0530c nanosleep+0x1c (/usr/lib/libc-2.31.so+0xa430c)
      iovisor#6  0x0000007fa0c051e4 sleep+0x34 (/usr/lib/libc-2.31.so+0xa41e4)
      iovisor#7  0x000000558a5a9608 flb_loop+0x28 (/usr/bin/fluent-bit+0x52608)
      iovisor#8  0x000000558a59f1c4 flb_main+0xa84 (/usr/bin/fluent-bit+0x481c4)
      iovisor#9  0x0000007fa0b85124 __libc_start_main+0xe4 (/usr/lib/libc-2.31.so+0x24124)
      iovisor#10 0x000000558a59d828 _start+0x34 (/usr/bin/fluent-bit+0x46828)
      -                fluent-bit (1238)
          1

      #0  0xffffffc01027daa4 generic_copy_file_checks+0x334
      iovisor#1  0xffffffc0102ba634 __handle_mm_fault+0x8dc
      iovisor#2  0xffffffc0102baa20 handle_mm_fault+0x168
      iovisor#3  0xffffffc010ad23c0 do_page_fault+0x148
      iovisor#4  0xffffffc010ad27c0 do_translation_fault+0xb0
      iovisor#5  0xffffffc0100816b0 do_mem_abort+0x50
      iovisor#6  0xffffffc0100843b0 el0_da+0x1c
      iovisor#7  0xffffffc01027daa4 generic_copy_file_checks+0x334
      --
  failed to get syms
      iovisor#8  0x0000007f8dc12648
      iovisor#9  0x0000007f8dc0aef8
      iovisor#10 0x0000007f8dc1c990
      iovisor#11 0x0000007f8dc08b0c
      iovisor#12 0x0000007f8dc08e48
      iovisor#13 0x0000007f8dc081c8
      -                PmLogCtl (2412)
          1

Signed-off-by: Eunseon Lee <[email protected]>
ekyooo added a commit to ekyooo/bcc that referenced this issue Feb 20, 2022
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)

Print backtrace of ip if it failed to get syms.

Before:
  # profile -d
      psiginfo
      vscanf
      __snprintf_chk
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      sd_event_exit
      sd_event_dispatch
      sd_event_run
      [unknown]
      __libc_start_main
      [unknown]
      -                systemd-journal (204)
          1

      xas_load
      xas_find
      filemap_map_pages
      __handle_mm_fault
      handle_mm_fault
      do_page_fault
      do_translation_fault
      do_mem_abort
      do_el0_ia_bp_hardening
      el0_ia
      xas_load
      --
  failed to get syms
      -                PmLogCtl (138757)
        1

After:
  # profile -d
      #0  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      iovisor#1  0xffffffc01009a93c el0_svc_handler+0x34
      iovisor#2  0xffffffc010084a08 el0_svc+0x8
      iovisor#3  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      --
      iovisor#4  0x0000007fa0bffd14 clock_nanosleep+0x94 (/usr/lib/libc-2.31.so+0x9ed14)
      iovisor#5  0x0000007fa0c0530c nanosleep+0x1c (/usr/lib/libc-2.31.so+0xa430c)
      iovisor#6  0x0000007fa0c051e4 sleep+0x34 (/usr/lib/libc-2.31.so+0xa41e4)
      iovisor#7  0x000000558a5a9608 flb_loop+0x28 (/usr/bin/fluent-bit+0x52608)
      iovisor#8  0x000000558a59f1c4 flb_main+0xa84 (/usr/bin/fluent-bit+0x481c4)
      iovisor#9  0x0000007fa0b85124 __libc_start_main+0xe4 (/usr/lib/libc-2.31.so+0x24124)
      iovisor#10 0x000000558a59d828 _start+0x34 (/usr/bin/fluent-bit+0x46828)
      -                fluent-bit (1238)
          1

      #0  0xffffffc01027daa4 generic_copy_file_checks+0x334
      iovisor#1  0xffffffc0102ba634 __handle_mm_fault+0x8dc
      iovisor#2  0xffffffc0102baa20 handle_mm_fault+0x168
      iovisor#3  0xffffffc010ad23c0 do_page_fault+0x148
      iovisor#4  0xffffffc010ad27c0 do_translation_fault+0xb0
      iovisor#5  0xffffffc0100816b0 do_mem_abort+0x50
      iovisor#6  0xffffffc0100843b0 el0_da+0x1c
      iovisor#7  0xffffffc01027daa4 generic_copy_file_checks+0x334
      --
  failed to get syms
      iovisor#8  0x0000007f8dc12648
      iovisor#9  0x0000007f8dc0aef8
      iovisor#10 0x0000007f8dc1c990
      iovisor#11 0x0000007f8dc08b0c
      iovisor#12 0x0000007f8dc08e48
      iovisor#13 0x0000007f8dc081c8
      -                PmLogCtl (2412)
          1

Signed-off-by: Eunseon Lee <[email protected]>
ekyooo added a commit to ekyooo/bcc that referenced this issue Mar 12, 2022
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)

Print backtrace of ip if it failed to get syms.

Before:
  # profile -d
      psiginfo
      vscanf
      __snprintf_chk
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      sd_event_exit
      sd_event_dispatch
      sd_event_run
      [unknown]
      __libc_start_main
      [unknown]
      -                systemd-journal (204)
          1

      xas_load
      xas_find
      filemap_map_pages
      __handle_mm_fault
      handle_mm_fault
      do_page_fault
      do_translation_fault
      do_mem_abort
      do_el0_ia_bp_hardening
      el0_ia
      xas_load
      --
  failed to get syms
      -                PmLogCtl (138757)
        1

After:
  # profile -d
      #0  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      iovisor#1  0xffffffc01009a93c el0_svc_handler+0x34
      iovisor#2  0xffffffc010084a08 el0_svc+0x8
      iovisor#3  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      --
      iovisor#4  0x0000007fa0bffd14 clock_nanosleep+0x94 (/usr/lib/libc-2.31.so+0x9ed14)
      iovisor#5  0x0000007fa0c0530c nanosleep+0x1c (/usr/lib/libc-2.31.so+0xa430c)
      iovisor#6  0x0000007fa0c051e4 sleep+0x34 (/usr/lib/libc-2.31.so+0xa41e4)
      iovisor#7  0x000000558a5a9608 flb_loop+0x28 (/usr/bin/fluent-bit+0x52608)
      iovisor#8  0x000000558a59f1c4 flb_main+0xa84 (/usr/bin/fluent-bit+0x481c4)
      iovisor#9  0x0000007fa0b85124 __libc_start_main+0xe4 (/usr/lib/libc-2.31.so+0x24124)
      iovisor#10 0x000000558a59d828 _start+0x34 (/usr/bin/fluent-bit+0x46828)
      -                fluent-bit (1238)
          1

      #0  0xffffffc01027daa4 generic_copy_file_checks+0x334
      iovisor#1  0xffffffc0102ba634 __handle_mm_fault+0x8dc
      iovisor#2  0xffffffc0102baa20 handle_mm_fault+0x168
      iovisor#3  0xffffffc010ad23c0 do_page_fault+0x148
      iovisor#4  0xffffffc010ad27c0 do_translation_fault+0xb0
      iovisor#5  0xffffffc0100816b0 do_mem_abort+0x50
      iovisor#6  0xffffffc0100843b0 el0_da+0x1c
      iovisor#7  0xffffffc01027daa4 generic_copy_file_checks+0x334
      --
      iovisor#8  0x0000007f8dc12648 [unknown]
      iovisor#9  0x0000007f8dc0aef8 [unknown]
      iovisor#10 0x0000007f8dc1c990 [unknown]
      iovisor#11 0x0000007f8dc08b0c [unknown]
      iovisor#12 0x0000007f8dc08e48 [unknown]
      iovisor#13 0x0000007f8dc081c8 [unknown]
      -                PmLogCtl (2412)
          1

Signed-off-by: Eunseon Lee <[email protected]>
ekyooo added a commit to ekyooo/bcc that referenced this issue Mar 17, 2022
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)]

Print backtrace of ip if it failed to get syms.

Before:
  # profile -d
      psiginfo
      vscanf
      __snprintf_chk
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      [unknown]
      sd_event_exit
      sd_event_dispatch
      sd_event_run
      [unknown]
      __libc_start_main
      [unknown]
      -                systemd-journal (204)
          1

      xas_load
      xas_find
      filemap_map_pages
      __handle_mm_fault
      handle_mm_fault
      do_page_fault
      do_translation_fault
      do_mem_abort
      do_el0_ia_bp_hardening
      el0_ia
      xas_load
      --
  failed to get syms
      -                PmLogCtl (138757)
        1

After:
  # profile -d
      #0  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      iovisor#1  0xffffffc01009a93c el0_svc_handler+0x34
      iovisor#2  0xffffffc010084a08 el0_svc+0x8
      iovisor#3  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
      --
      iovisor#4  0x0000007fa0bffd14 clock_nanosleep+0x94 (/usr/lib/libc-2.31.so+0x9ed14)
      iovisor#5  0x0000007fa0c0530c nanosleep+0x1c (/usr/lib/libc-2.31.so+0xa430c)
      iovisor#6  0x0000007fa0c051e4 sleep+0x34 (/usr/lib/libc-2.31.so+0xa41e4)
      iovisor#7  0x000000558a5a9608 flb_loop+0x28 (/usr/bin/fluent-bit+0x52608)
      iovisor#8  0x000000558a59f1c4 flb_main+0xa84 (/usr/bin/fluent-bit+0x481c4)
      iovisor#9  0x0000007fa0b85124 __libc_start_main+0xe4 (/usr/lib/libc-2.31.so+0x24124)
      iovisor#10 0x000000558a59d828 _start+0x34 (/usr/bin/fluent-bit+0x46828)
      -                fluent-bit (1238)
          1

      #0  0xffffffc01027daa4 generic_copy_file_checks+0x334
      iovisor#1  0xffffffc0102ba634 __handle_mm_fault+0x8dc
      iovisor#2  0xffffffc0102baa20 handle_mm_fault+0x168
      iovisor#3  0xffffffc010ad23c0 do_page_fault+0x148
      iovisor#4  0xffffffc010ad27c0 do_translation_fault+0xb0
      iovisor#5  0xffffffc0100816b0 do_mem_abort+0x50
      iovisor#6  0xffffffc0100843b0 el0_da+0x1c
      iovisor#7  0xffffffc01027daa4 generic_copy_file_checks+0x334
      --
      iovisor#8  0x0000007f8dc12648 [unknown]
      iovisor#9  0x0000007f8dc0aef8 [unknown]
      iovisor#10 0x0000007f8dc1c990 [unknown]
      iovisor#11 0x0000007f8dc08b0c [unknown]
      iovisor#12 0x0000007f8dc08e48 [unknown]
      iovisor#13 0x0000007f8dc081c8 [unknown]
      -                PmLogCtl (2412)
          1

Signed-off-by: Eunseon Lee <[email protected]>
Bojun-Seo added a commit to Bojun-Seo/bcc that referenced this issue Nov 7, 2022
doublefree tool can detect double free on user space

Usage: doublefree [OPTION...]
Detect and report double free error.

Either -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
    doublefree -k                  # Detect doublefree on kernel

  -k, --kernel               Kernel threads only (no user threads)
  -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 example:
$ ~/test/doublefree_generator &
[1] 48310
$ sudo ./doublefree -p 48310
Warn: Is this process alive? pid: 48310
Found double free...
Allocation happended on:
stack_id: 50292
        iovisor#1 0x0055b302c34219 foo
        iovisor#2 0x0055b302c341d0 main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

First deallocation happended on:
stack_id: 57265
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c341ea main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

Second deallocation happended on:
stack_id: 2974
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c342eb baz
        iovisor#3 0x0055b302c34200 main
        iovisor#4 0x007f5d6379dd90 __libc_init_first

Source code of test program:
$ cat Makefile
OBJ = doublefree_generator.o foobar.o baz.o
TARGET = doublefree_generator

all: clean $(TARGET)

$(TARGET): $(OBJ)
	gcc -o $@ $^

%.o: %.c
	gcc -c $< -o $@

clean:
	rm -f $(OBJ) $(TARGET)

$ cat doublefree_generator.c
\#include <unistd.h>
\#include "foobar.h"
\#include "baz.h"

int main(int argc, char* argv[]) {
  sleep(50);
  int *val = foo();
  *val = 33;
  bar(val);
  *val = 84;
  baz(val);
  return 0;
}

$ cat foobar.h
\#include <stdio.h>

int* foo();
void bar(int* p);

$ cat foobar.c
\#include <stdlib.h>
\#include "foobar.h"

int* foo() {
  return (int*)malloc(sizeof(int));
}

void bar(int* p) {
  printf("bar: %p\n", p);
  free(p);
}

$ cat baz.h
\#include <stdio.h>

void baz(int* p);

$ cat baz.c
\#include <stdlib.h>
\#include <stdbool.h>
\#include "baz.h"

void func(int* p) {
  while (true) {
    if (p != NULL) {
      printf("free %d\n", *p);
      free(p);
      break;
    }
  }
}

void baz(int* p) {
  printf("baz: %p\n", p);
  printf("bazz: %d\n", *p);
  func(p);
}
Bojun-Seo added a commit to Bojun-Seo/bcc that referenced this issue Nov 7, 2022
doublefree tool can detect double free on user space

Usage: doublefree [OPTION...]
Detect and report double free error.

Either -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
    doublefree -k                  # Detect doublefree on kernel

  -k, --kernel               Kernel threads only (no user threads)
  -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 example:
$ ~/test/doublefree_generator &
[1] 48310
$ sudo ./doublefree -p 48310
Warn: Is this process alive? pid: 48310
Found double free...
Allocation happended on:
stack_id: 50292
        iovisor#1 0x0055b302c34219 foo
        iovisor#2 0x0055b302c341d0 main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

First deallocation happended on:
stack_id: 57265
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c341ea main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

Second deallocation happended on:
stack_id: 2974
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c342eb baz
        iovisor#3 0x0055b302c34200 main
        iovisor#4 0x007f5d6379dd90 __libc_init_first

Source code of test program:
$ cat Makefile
OBJ = doublefree_generator.o foobar.o baz.o
TARGET = doublefree_generator

all: clean $(TARGET)

$(TARGET): $(OBJ)
	gcc -o $@ $^

%.o: %.c
	gcc -c $< -o $@

clean:
	rm -f $(OBJ) $(TARGET)

$ cat doublefree_generator.c
\#include <unistd.h>
\#include "foobar.h"
\#include "baz.h"

int main(int argc, char* argv[]) {
  sleep(50);
  int *val = foo();
  *val = 33;
  bar(val);
  *val = 84;
  baz(val);
  return 0;
}

$ cat foobar.h
\#include <stdio.h>

int* foo();
void bar(int* p);

$ cat foobar.c
\#include <stdlib.h>
\#include "foobar.h"

int* foo() {
  return (int*)malloc(sizeof(int));
}

void bar(int* p) {
  printf("bar: %p\n", p);
  free(p);
}

$ cat baz.h
\#include <stdio.h>

void baz(int* p);

$ cat baz.c
\#include <stdlib.h>
\#include <stdbool.h>
\#include "baz.h"

void func(int* p) {
  while (true) {
    if (p != NULL) {
      printf("free %d\n", *p);
      free(p);
      break;
    }
  }
}

void baz(int* p) {
  printf("baz: %p\n", p);
  printf("bazz: %d\n", *p);
  func(p);
}
Bojun-Seo added a commit to Bojun-Seo/bcc that referenced this issue Nov 9, 2022
doublefree tool can detect double free on user space

Usage: doublefree [OPTION...]
Detect and report double free error.

Either -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
    doublefree -k                  # Detect doublefree on kernel

  -k, --kernel               Kernel threads only (no user threads)
  -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 example:
$ ~/test/doublefree_generator &
[1] 48310
$ sudo ./doublefree -p 48310
Warn: Is this process alive? pid: 48310
Found double free...
Allocation happended on:
stack_id: 50292
        iovisor#1 0x0055b302c34219 foo
        iovisor#2 0x0055b302c341d0 main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

First deallocation happended on:
stack_id: 57265
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c341ea main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

Second deallocation happended on:
stack_id: 2974
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c342eb baz
        iovisor#3 0x0055b302c34200 main
        iovisor#4 0x007f5d6379dd90 __libc_init_first

Source code of test program:
$ cat Makefile
OBJ = doublefree_generator.o foobar.o baz.o
TARGET = doublefree_generator

all: clean $(TARGET)

$(TARGET): $(OBJ)
	gcc -o $@ $^

%.o: %.c
	gcc -c $< -o $@

clean:
	rm -f $(OBJ) $(TARGET)

$ cat doublefree_generator.c
\#include <unistd.h>
\#include "foobar.h"
\#include "baz.h"

int main(int argc, char* argv[]) {
  sleep(50);
  int *val = foo();
  *val = 33;
  bar(val);
  *val = 84;
  baz(val);
  return 0;
}

$ cat foobar.h
\#include <stdio.h>

int* foo();
void bar(int* p);

$ cat foobar.c
\#include <stdlib.h>
\#include "foobar.h"

int* foo() {
  return (int*)malloc(sizeof(int));
}

void bar(int* p) {
  printf("bar: %p\n", p);
  free(p);
}

$ cat baz.h
\#include <stdio.h>

void baz(int* p);

$ cat baz.c
\#include <stdlib.h>
\#include <stdbool.h>
\#include "baz.h"

void func(int* p) {
  while (true) {
    if (p != NULL) {
      printf("free %d\n", *p);
      free(p);
      break;
    }
  }
}

void baz(int* p) {
  printf("baz: %p\n", p);
  printf("bazz: %d\n", *p);
  func(p);
}
Bojun-Seo added a commit to Bojun-Seo/bcc that referenced this issue Nov 21, 2022
doublefree tool can detect double free on user space

Usage: doublefree [OPTION...]
Detect and report double free error.

Either -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
    doublefree -k                  # Detect doublefree on kernel

  -k, --kernel               Kernel threads only (no user threads)
  -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 example:
$ ~/test/doublefree_generator &
[1] 48310
$ sudo ./doublefree -p 48310
Warn: Is this process alive? pid: 48310
Found double free...
Allocation happended on:
stack_id: 50292
        iovisor#1 0x0055b302c34219 foo
        iovisor#2 0x0055b302c341d0 main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

First deallocation happended on:
stack_id: 57265
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c341ea main
        iovisor#3 0x007f5d6379dd90 __libc_init_first

Second deallocation happended on:
stack_id: 2974
        iovisor#1 0x007f5d63819460 free
        iovisor#2 0x0055b302c342eb baz
        iovisor#3 0x0055b302c34200 main
        iovisor#4 0x007f5d6379dd90 __libc_init_first

Source code of test program:
$ cat Makefile
OBJ = doublefree_generator.o foobar.o baz.o
TARGET = doublefree_generator

all: clean $(TARGET)

$(TARGET): $(OBJ)
	gcc -o $@ $^

%.o: %.c
	gcc -c $< -o $@

clean:
	rm -f $(OBJ) $(TARGET)

$ cat doublefree_generator.c
\#include <unistd.h>
\#include "foobar.h"
\#include "baz.h"

int main(int argc, char* argv[]) {
  sleep(50);
  int *val = foo();
  *val = 33;
  bar(val);
  *val = 84;
  baz(val);
  return 0;
}

$ cat foobar.h
\#include <stdio.h>

int* foo();
void bar(int* p);

$ cat foobar.c
\#include <stdlib.h>
\#include "foobar.h"

int* foo() {
  return (int*)malloc(sizeof(int));
}

void bar(int* p) {
  printf("bar: %p\n", p);
  free(p);
}

$ cat baz.h
\#include <stdio.h>

void baz(int* p);

$ cat baz.c
\#include <stdlib.h>
\#include <stdbool.h>
\#include "baz.h"

void func(int* p) {
  while (true) {
    if (p != NULL) {
      printf("free %d\n", *p);
      free(p);
      break;
    }
  }
}

void baz(int* p) {
  printf("baz: %p\n", p);
  printf("bazz: %d\n", *p);
  func(p);
}
Bojun-Seo added a commit to Bojun-Seo/bcc that referenced this issue Aug 28, 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 Nov 2, 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 Nov 2, 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 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 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants