Details
Blocker Description
Can be seen in stack traces like in MDEV-14710. To quote here
*** buffer overflow detected ***: /usr/sbin/mysqld terminated
|
======= Backtrace: =========
|
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f3e6272abcb]
|
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f3e627b3227]
|
/lib/x86_64-linux-gnu/libc.so.6(+0xf7360)[0x7f3e627b1360]
|
/lib/x86_64-linux-gnu/libc.so.6(+0xf919a)[0x7f3e627b319a]
|
/usr/sbin/mysqld(my_addr_resolve+0x4c)[0x5612759e2cfc]
|
/usr/sbin/mysqld(my_print_stacktrace+0x1bb)[0x5612759cc4fb]
|
/usr/sbin/mysqld(handle_fatal_signal+0x3bd)[0x561275511a4d]
|
...
|
Attachments
Activity
This seems to be it: https://stackoverflow.com/questions/22827510/how-to-avoid-bad-fd-set-buffer-overflow-crash
supposedly rewriting select to poll should fix it.
alternatively, a hack like for (f=10; f < 30; f++) close(f); could, perhaps, alleviate the issue. but only if no cleaner solution would help
A tentative fix for this was done by moving stack variables out to global space (code is run single threaded anyway) and switching select to poll. poll can also error out with ENOMEM, which represents Kernel data structures were not allocated due to out-of-memory. There's no way to realistically fix that though.
Let's see if this fix is any good as I can't quite reproduce it locally.
technically, it could've happen that the memory was corrupted before, and only detected in my_addr_resolve().