https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #18 from Martin Liška <marxin at gcc dot gnu.org> ---
I can confirm I can reproduce it. Now with just AddressSanitizer I see:
==5488==ERROR: AddressSanitizer: unknown-crash on address 0x7fa04c0092e0 at pc
0x000005ee3108 bp 0x7fa04c0091b0 sp 0x7fa04c0091a0
WRITE of size 32 at 0x7fa04c0092e0 thread T1
...
SUMMARY: AddressSanitizer: unknown-crash tests/cql_test_env.cc:247 in
single_node_cql_env::create_keyspace(seastar::basic_sstring<char, unsigned int,
15u>)
Shadow bytes around the buggy address:
0x0ff4897f9200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff4897f9210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff4897f9220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff4897f9230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff4897f9240: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2
=>0x0ff4897f9250: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2[00]00 f8 f8
0x0ff4897f9260: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
And I realized there's one interesting function in back-trace:
0x7fa04c0092e0 is located 119520 bytes inside of 131072-byte region
[0x7fa04bfec000,0x7fa04c00c000)
allocated by thread T1 here:
#0 0x7fa060d984a0 in posix_memalign (/lib64/libasan.so.4+0xdf4a0)
#1 0x7cef31 in operator new[](unsigned long, seastar::with_alignment)
core/memory.cc:1754
#2 0x8a0704 in seastar::thread_context::make_stack() core/thread.cc:169
#3 0x89ff7d in
seastar::thread_context::thread_context(seastar::thread_attributes,
std::function<void ()>) core/thread.cc:153
Where in #2 there's a call of make_stack. Maybe that does some magic which
breaks a shadow stack? Can you please investigate that?
