ASan needs to keep track of all the libraries loaded during the process lifetime

[ramosian-glider]

Originally reported on Google Code with ID 89

In the following situation:

> malloc or free gets calls from xyz.dylib
> xyz.dylib gets unloaded 
> a bug happens and we want to report the stack trace of malloc/free which has xyz.dylib
in it. 

we need to restore the library layout at the stack collection time in order to symbolize
it correctly.

Possible solution:

> We keep an epoch counter that is incremented for each dlopen and 
> dlclose (we also write down the [un]loaded library and the slide value 
> each time we do that). For each stack we just sacrifice one frame to 
> keep the corresponding counter. When symbolizing, it's easy to replay 
> the sequence of dlopen/dlclose events and find out which libraries 
> were loaded.

Reported by ramosian.glider on 2012-07-18 09:21:08

[ramosian-glider]

Reported by pbos@webrtc.org on 2015-04-23 09:21:22

• Blocking: #3402

[obfuscated]

Any chance for this getting fixed some day?

[kcc]

@obfuscated we are not working on this. What exactly do you need?

[obfuscated]

@kcc I'm getting unknown modules lines in the callstacks printed by the leak report from asan.

Our application uses plugins (dlopened .so files on linux) quite extensively, so the leak reports aren't too useful. Also there are some leaks that I want to suppress, but I'm not sure I can, because of the lines.

I'm using clang-3.9.1, centos 6, linux.

[kcc]

Understood.
Yes, this is the exact problem discussed here and no, we don't have plans to address it in near future, sorry.
The reasons are that a) this is not a very common use case among other users and b) implementation is unlikely to be simple and we alreay have enough complexity to maintain.

I think there could also be a simple workaround on your side: don't dlclose anything when testing under asan/lsan

[obfuscated]

OK, going with the no-dlclose workaround. I remembered that I've done this for valgrind, but there is another place in our code that does dlclose calls, so patching these resolved the problem.

I've stopped seeing the leaks for the global variables in dlopened shared libraries, but I guess this is expected.