[asan] failure to detect memory leaks

[PikachuHyA]

reproducer
see https://godbolt.org/z/6YGdnn634

// main.cc
struct Foo {
  struct Foo *other;
};
int main() {
  auto f1 = new Foo();
  auto f2 = new Foo();
  f1->other = f2;
  f2->other = f1;
  return 0;
}

However, the following memory leaks detected.

see https://godbolt.org/z/n6jWbYTqY

struct Foo {
  struct Foo *other;
};
int main() {
  auto f1 = new Foo();
  auto f2 = new Foo();
  f1->other = f2;
  // highlight here
  // f2->other = f1;
  return 0;
}

Note: GCC can detect the memory leaks.
if use -fsanitize=leak, the memory leaks detected.

[frederick-vs-ja]

It seems that Clang's ASan obstructed LSan in the circularly referential case.

[PikachuHyA]

Thanks for your comments.

It seems that Clang's ASan obstructed LSan in the circularly referential case.

Could you please share any suggestions on how to resolve this issue?

[cabbaken]

It works fine with -fsanitize=leak, may be there are some issue with these two option.

[cabbaken]

This piece of code will keep asan thread running background, make it a runaway thread.
I will work on this issue in a few days.

[cabbaken]

This piece of code will keep asan thread running background, make it a runaway thread.

I am sorry about my false judge. The reason about the misbehavior of asan thread is my additional log, it may cause some damage to the stack.

And let's back to the problem, to be simple and clear, in short, the reason may be the different way of gcc and clang treat to new.
And it works fine with this:

struct Foo {
   Foo *other;
};
int main() {
  auto f2 = new Foo();
  auto f1 = new Foo();

  f1->other = f2;
  f2->other = f1;
  auto t = &f1;
  return 0;
}

In fact, gcc will reproduce this error(not sure if this is the same root cause) with this code:

struct Foo {
   Foo *other;
   char a[8185];
};
int main() {
  auto f1 = new Foo();
  auto f2 = new Foo();
  f1->other = f2;
  f2->other = f1;
  return 0;
}

I am not sure how gcc asan handles this, here is llvm asan log(with my additional log):

0x72d1d8fe0010 0x72d1d8fe0030
==444930==Stack at 0x7ffd17151000-0x7ffd17951000 (SP = 0x7ffd1794f400).
==444930==Scanning STACK range 0x7ffd1794f400-0x7ffd17951000.
==444930==Qiuruoyu telling you that 0x72d1d8fe0000 tag before modification: 2
==444930==Qiuruoyu warning: 0x72d1d8fe0000 set_tag(2)
==444930==Qiuruoyu telling you that 0x72d1d8fe0000 tag after modification: 2
==444930==0x7ffd1794f5b8: found 0x72d1d8fe0010 pointing into chunk 0x72d1d8fe0010-0x72d1d8fe0018 of size 8.
==444930==Qiuruoyu telling you that 0x72d1d8fe0020 tag before modification: 2
==444930==Qiuruoyu warning: 0x72d1d8fe0020 set_tag(2)
==444930==Qiuruoyu telling you that 0x72d1d8fe0020 tag after modification: 2
==444930==0x7ffd1794f5c0: found 0x72d1d8fe0030 pointing into chunk 0x72d1d8fe0030-0x72d1d8fe0038 of size 8.

0x72d1d8fe0010 and 0x72d1d8fe0030 is the address of leaked memory.
And let's look up the log of -fsanitize=leak(which can function normally):

==456932==Scanning HEAP range 0x501000000000-0x501000000008.
==456932==Qiuruoyu telling you that 0x501dffffffe0 tag before modification: 1
==456932==Qiuruoyu warning: set_tag(1)
==456932==Qiuruoyu telling you that 0x501dffffffe0 tag after modification: 1
==456932==0x501000000000: found 0x501000000010 pointing into chunk 0x501000000010-0x501000000018 of size 8.
==456932==Scanning HEAP range 0x501000000010-0x501000000018.
==456932==Qiuruoyu telling you that 0x501dfffffff0 tag before modification: 1
==456932==Qiuruoyu warning: set_tag(1)
==456932==Qiuruoyu telling you that 0x501dfffffff0 tag after modification: 1
==456932==0x501000000010: found 0x501000000000 pointing into chunk 0x501000000000-0x501000000008 of size 8.

The -fsanitize=address log tells that it found two pointers in stack(which should be reclaimed), and then it make the content(the two chunk of leaked memory) be tagged kReachable(Why the variable can be accessed here? I am new to asan, and I need time to read more code.).
And -fsanitize=leak would check the chunk later than -fsanitize=address, it may be some issue with the timing of asan calling lsan.
Or is this misbehavior of clang? I might need some time to investigate, or does anyone have insights that could help?

[cabbaken]

I have a new discovery:
There is a probability that code

struct Foo {
  struct Foo *other;
};
int main() {
  Foo *f1 = new Foo();
  Foo *f2 = new Foo();
  f1->other = f2;
  f2->other = f1;
  std::cout<<&f1<<" "<<&f2<<"\n";    // this line is necessary to make leak detection possiable with -fsanitize=address

  return 0;
}

detect leak with -fsanitize=address, I write a script here to calculate the detect rate:

#!/usr/bin/bash

EXE=${your_executable}

cnt=0

for ((i=0; i<$1; i++)); do
  LSAN_OPTIONS=verbosity=1:log_threads=1:log_pointers=1 ${EXE} 2>&1|grep "Indirect leak" >/dev/null
  res=$?
  if [[ $res == 0 ]]; then
    ((cnt++))
  fi
done
echo $cnt

The rate is about 50% on my machine.
I think the main reason may be here. atexit() will register functions that will be called when program terminated, and the program may not completely handle the end state of the stack when the lsan run(and it's possible that asan does something delay the handle of stack), it may depend on the timing of calling atexit().
And I found that they use two different atexit()(why?) with llvm-objdump -D:
leak:

00000000000391c0 <atexit>:
   391c0: f3 0f 1e fa                  	endbr64
   391c4: 48 8b 15 95 7f 01 00         	movq	0x17f95(%rip), %rdx     # 0x51160 <__dso_handle>
   391cb: 31 f6                        	xorl	%esi, %esi
   391cd: ff 25 c5 7d 01 00            	jmpq	*0x17dc5(%rip)          # 0x50f98 <syslog@GLIBC_2.2.5+0x50f98> (And this is a wrong parse here, thanks llvm-objdump)
   391d3: 66 2e 0f 1f 84 00 00 00 00 00	nopw	%cs:(%rax,%rax)
   391dd: 0f 1f 00                     	nopl	(%rax)

address:

0000000000115280 <atexit>:
  115280: f3 0f 1e fa                  	endbr64
  115284: 48 8b 15 9d ae 03 00         	movq	0x3ae9d(%rip), %rdx     # 0x150128 <__dso_handle>
  11528b: 31 f6                        	xorl	%esi, %esi
  11528d: e9 7d 10 f3 ff               	jmp	0x4630f <__interceptor_trampoline___cxa_atexit>
  115292: 90                           	nop
  115293: 66 2e 0f 1f 84 00 00 00 00 00	nopw	%cs:(%rax,%rax)
  11529d: 0f 1f 00                     	nopl	(%rax)

I will keep tracking this problem when I have free time.
If you have any suggestion or correction, please let me know. I am not familiar with compiler-rt(I am just a newbie though), so this is just my "guess".
Could anyone help? You could just tell me that if this is possible so I won't walk along with such a wrong way.
Repeat: This may not be the correct anaswer, it's just my suspection!

[cabbaken]

Could anyone help?
@vitalybuka @ramosian-glider
I think the key point may be this line:

  std::cout<<&f1<<" "<<&f2<<"\n";    // this line is necessary to make leak detection possiable with -fsanitize=address -O0

Why this make it possible asan can detect leak? Is it related to the optimization of clang or llvm?