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

libasan: keep debuginfo on dlclose #53566

Open
diorcety opened this issue Feb 3, 2022 · 1 comment
Open

libasan: keep debuginfo on dlclose #53566

diorcety opened this issue Feb 3, 2022 · 1 comment
Labels
compiler-rt:asan Address sanitizer

Comments

@diorcety
Copy link

diorcety commented Feb 3, 2022

Currently if there is a leak in the code of a dynamic loaded library, which is already closed when the program's end, the report contains addresses without any information but "unknown module".
Seem's to be a known issue in many asan: google/sanitizers#89. but which is resolved in valgrind with the fix associated to https://bugs.kde.org/show_bug.cgi?id=79362

@EugeneZelenko EugeneZelenko added compiler-rt:asan Address sanitizer and removed new issue labels Feb 3, 2022
@syzop
Copy link

syzop commented Mar 28, 2022

A feature like this would help us a lot.

Current situation

Backtraces for us look like this now:

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x560790cbdfb2 in calloc (/home/irc/unrealircd/bin/unrealircd+0x11cfb2)
    #1 0x560790e08539 in safe_alloc /home/irc/u6/src/support.c:715:6
    #2 0x7f72950c7ec9  (<unknown module>)
    #3 0x7f72950c5fdc  (<unknown module>)
    #4 0x7f72950c58c6  (<unknown module>)
    #5 0x560790d98b31 in _conf_set /home/irc/u6/src/conf.c:7840:13
    #6 0x560790d57221 in config_run_blocks /home/irc/u6/src/conf.c:2834:10

Stack frame 5, the _conf_set is code calling a linked list of "hooks" where modules can plug in. This particular hook is used by 39 different modules. Long story short: if I see a backtrace like this I really have no idea which module has a problem.

Not calling dlclose() is not an option

Someone mentioned in google/sanitizers#89 people should simply not call dlclose(). But then we would miss bugs/leaks that are otherwise detected. Like a module which has a global variable char *xyz that receives allocated memory, if we would skip calling dlclose() then it is no longer (detected as) a leak.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler-rt:asan Address sanitizer
Projects
None yet
Development

No branches or pull requests

3 participants