By design, AddressSanitizer will allocate some "sentinel" areas in stack frames so that it can better catch buffer overflows, by trapping access to memory addresses that reside between stack-allocated variables.
Apparently, something has been changed in recent compilers, and I am seeing a need for a larger thread stack size when using -DWITH_ASAN=ON with GCC 12.3.0, GCC 13.2.0, or clang 16.0.6. The minimum stack size to pass bootstrap is smaller for non-debug builds, and smaller for GCC 12 than for GCC 13. Here is an example from clang 16.0.6, CMAKE_BUILD_TYPE=RelWithDebInfo and WITH_ASAN=ON:
|
10.6 44b9e4169412205f2f1d013d3346420aee9d09d5
|
main.1st [ fail ] Found warnings/errors in server log file!
|
Test ended at 2023-11-17 13:53:43
|
line
|
2023-11-17 13:53:42 0 [ERROR] Could not open mysql.plugin table: "Thread stack overrun: 6566560 bytes used of a 5242880 byte stack, and 81920 bytes needed. Consider increasing the thread_stack system variable.". Some plugins may be not loaded
|
2023-11-17 13:53:42 0 [Warning] Can't open and lock time zone table: Thread stack overrun: 8642784 bytes used of a 5242880 byte stack, and 81920 bytes needed. Consider increasing the thread_stack system variable. trying to live without them
|
2023-11-17 13:53:42 0 [ERROR] Can't open the mysql.func table. Please run mysql_upgrade to create it.
|
I don’t think that this is a bug in our actual code or the stack overflow detection, just an issue with the build parameters. The following patch fixes this for me:
diff --git a/include/my_pthread.h b/include/my_pthread.h
|
index 3e68538b424..31157c9f063 100644
|
--- a/include/my_pthread.h
|
+++ b/include/my_pthread.h
|
@@ -667,15 +667,11 @@ extern void my_mutex_end(void);
|
We need to have at least 256K stack to handle calls to myisamchk_init()
|
with the current number of keys and key parts.
|
*/
|
-#if defined(__SANITIZE_ADDRESS__) || defined(WITH_UBSAN)
|
-#ifndef DBUG_OFF
|
-#define DEFAULT_THREAD_STACK (1024*1024L)
|
-#else
|
-#define DEFAULT_THREAD_STACK (383*1024L) /* 392192 */
|
-#endif
|
-#else
|
-#define DEFAULT_THREAD_STACK (292*1024L) /* 299008 */
|
-#endif
|
+# if defined(__SANITIZE_ADDRESS__) || defined(WITH_UBSAN)
|
+# define DEFAULT_THREAD_STACK (9L<<20)
|
+# else
|
+# define DEFAULT_THREAD_STACK (292*1024L) /* 299008 */
|
+# endif
|
#endif
|
|
#define MY_PTHREAD_LOCK_READ 0
|
I think that to be on the safe side, we’d better use 10 MiB instead of the above 9 MiB. That is what I have been using in my local builds recently.
Apparently, on our CI systems, the compilers used for ASAN builds are older, because the problem has not occurred there.
MDEV-33210 Several performance_schema tests fail due to explicit (too small for ASAN) thread_stack
By design, AddressSanitizer will allocate some "sentinel" areas in stack frames so that it can better catch buffer overflows, by trapping access to memory addresses that reside between stack-allocated variables.
Apparently, something has been changed in recent compilers, and I am seeing a need for a larger thread stack size when using -DWITH_ASAN=ON with GCC 12.3.0, GCC 13.2.0, or clang 16.0.6. The minimum stack size to pass bootstrap is smaller for non-debug builds, and smaller for GCC 12 than for GCC 13. Here is an example from clang 16.0.6, CMAKE_BUILD_TYPE=RelWithDebInfo and WITH_ASAN=ON:
10.6 44b9e4169412205f2f1d013d3346420aee9d09d5
main.1st [ fail ] Found warnings/errors in server log file!Test ended at 2023-11-17 13:53:43line2023-11-17 13:53:42 0 [ERROR] Could not open mysql.plugin table: "Thread stack overrun: 6566560 bytes used of a 5242880 byte stack, and 81920 bytes needed. Consider increasing the thread_stack system variable.". Some plugins may be not loaded2023-11-17 13:53:42 0 [Warning] Can't open and lock time zone table: Thread stack overrun: 8642784 bytes used of a 5242880 byte stack, and 81920 bytes needed. Consider increasing the thread_stack system variable. trying to live without them2023-11-17 13:53:42 0 [ERROR] Can't open the mysql.func table. Please run mysql_upgrade to create it.I don’t think that this is a bug in our actual code or the stack overflow detection, just an issue with the build parameters. The following patch fixes this for me:
diff --git a/include/my_pthread.h b/include/my_pthread.hindex 3e68538b424..31157c9f063 100644--- a/include/my_pthread.h+++ b/include/my_pthread.h@@ -667,15 +667,11 @@ extern void my_mutex_end(void);We need to have at least 256K stack to handle calls to myisamchk_init()with the current number of keys and key parts.*/-#if defined(__SANITIZE_ADDRESS__) || defined(WITH_UBSAN)-#ifndef DBUG_OFF-#define DEFAULT_THREAD_STACK (1024*1024L)-#else-#define DEFAULT_THREAD_STACK (383*1024L) /* 392192 */-#endif-#else-#define DEFAULT_THREAD_STACK (292*1024L) /* 299008 */-#endif+# if defined(__SANITIZE_ADDRESS__) || defined(WITH_UBSAN)+# define DEFAULT_THREAD_STACK (9L<<20)+# else+# define DEFAULT_THREAD_STACK (292*1024L) /* 299008 */+# endif#endifI think that to be on the safe side, we’d better use 10 MiB instead of the above 9 MiB. That is what I have been using in my local builds recently.
Apparently, on our CI systems, the compilers used for ASAN builds are older, because the problem has not occurred there.