MDEV-39113 addr2line stack resolver deterimental#4822
MDEV-39113 addr2line stack resolver deterimental#4822grooverdan wants to merge 1 commit intoMariaDB:10.11from
Conversation
MSAN/ASAN test environment, the addr2line was so high in memory utilization that it was the pick of the OOM killer to resolve the OOM situation. In addition to this harmful effect, its resolution is of such a poor quality compared to a) the implementation of the sanitizers themselves, and b) the core dump and gdb resolution that is most common for these environments that use these instrumented builds. To resolve this, under MSAN and ASAN builds the stack-trace defaults to 0 (off). MariaDB-backup also forces the enabling of stack-trace. Disabling this unconditionally reduces the risk of a user operational impact if a lengthly stacktrace starting in a mariabackup critical locked period.
grooverdan
added
the
MariaDB Foundation
dr-m
left a comment
dr-m
left a comment
There was a problem hiding this comment.
This looks reasonable to me. I think that we should ask @vuvova as well.
Personally, I would disable opt_stack_trace by default everywhere, because based on MDEV-21010 we know that it can cause the server process to hang when malloc() or free() crashes because of heap memory corruption.
You can maybe disable it on Linux everywhere, because it does not really work. But we do not know of process hangs anywhere else. |
|
I'm very much in favour of total disable by default too. The OS is better at capturing stacks and with instruction can result in something actually usable in a bug report. |
We absolutely agree that on Linux, the crash stacktrace is unusable. If you mean Linux by The OS, ok. You can totally disable it there. But if you show me a bug report on Windows, where it is not usable, I'd agree in general. Until then, I propose you disable it, only where it does not really work. |
4 participants
MSAN/ASAN test environment, the addr2line was so high in memory utilization that it was the pick of the OOM killer to resolve the OOM situation.
In addition to this harmful effect, its resolution is of such a poor quality compared to a) the implementation of the sanitizers themselves, and b) the core dump and gdb resolution that is most common for these environments that use these instrumented builds.
To resolve this, under MSAN and ASAN builds the stack-trace defaults to 0 (off).
MariaDB-backup also forces the enabling of stack-trace. Disabling this unconditionally reduces the risk of a user operational impact if a lengthly stacktrace starting in a mariabackup critical locked period.