https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021

--- Comment #19 from Avi Kivity <a...@cloudius-systems.com> ---
(In reply to Martin Liška from comment #18)
> 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?

The code uses user-level threads (makecontext/setcontext etc). It annotates the
new stack during the switch, see for example
https://github.com/scylladb/seastar/blob/master/core/thread.cc#L66. Supposedly
it's correct, but perhaps something is missing.

Reply via email to