On Tue, Apr 13, 2021 at 11:55 AM Wei Chen <[email protected]> wrote: > > Hi all, > > I'm recently learning Address Sanitizer code and learned that the runtime > library is designed to replace the glibc malloc/free with our customized ones > so that we can insert red zone before and after the allocated region. > > From the code, I've learned that such a replacement is implemented by > changing the runtime library load priority. By writing our malloc/free with > exactly the same function signature as the library ones, and letting our > runtime library being loaded before glibc, our malloc/free function will be > invoked by the user program. > > However, we are not able to invoke printf library functions anymore, cause > printf depends on malloc, therefore, each time when printf is invoked when > implementing asan runtime library, it will call our malloc instead of library > malloc. > > Why not just implement our malloc and free to another name, say asan_malloc > and asan_free? In that case, we can replace the malloc invocation with > asan_malloc invocation during compilation, and no need to write a totally new > printf. Is there any reason to have the same name?
Hi Wei, One reason to define them with the same name is that it allows to intercept malloc/free calls in code compiled without ASAN (e.g. libc's getline). We won't check accesses to the buffer inside of libc, but we will check them in the user code that uses the buffer. Another reason is probably more important: in some cases memory is allocated in one library and freed in another (again - getline). In that case we may get a fatal crash/memory corruption is malloc/free are not matching. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/CACT4Y%2BZOzqECfZzYkr%2BXvLs7enq%2B%2BxxmrKoULAwA3LSza%3DNXwQ%40mail.gmail.com.
