MDEV-14229: Stack trace is not resolved for shared objects
Resolving a stacktrace including functions in dynamic libraries requires us to look inside the libraries for the symbols. Addr2line needs to be started with the correct binary for each address on the stack. To do this, figure out which library it is using dladdr, then if the addr2line binary was started with a different binary, fork it again with the correct one. We only have one addr2line process running at any point during the stacktrace resolving step. The maximum number of forks for addr2line should generally be around 6. One for server stacktrace code, one for plugin code, one when going back into server code, one for pthread library, one for libc, one for the _start function in the server. More can come up if plugin calls server function which goes back to a plugin, etc.
Showing
Please register or sign in to comment