[MDEV-26387] SIGSEGV in __strlen_avx2 Created: 2021-08-17  Updated: 2022-05-10  Resolved: 2022-05-10

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Ramesh Sivaraman Assignee: Ramesh Sivaraman
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

The crash is from multi thread pquery run

10.2.41

Core was generated by `/test/mtest/GAL_MD170821-mariadb-10.2.41-linux-x86_64-dbg/bin/mysqld --defaults'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000070000002 in ?? ()
[Current thread is 1 (Thread 0xfba38947700 (LWP 3912067))]
(gdb) bt
#0  0x0000000070000002 in ?? ()
#1  0x0000562c75e47766 in _raw_syscall () at /home/roc/rr/rr/src/preload/raw_syscall.S:120
#2  0x0000562c75e4304e in traced_raw_syscall (call=<optimized out>) at /home/roc/rr/rr/src/preload/syscallbuf.c:272
#3  0x0000562c75e464d1 in syscall_hook_internal (call=0x14f6e51d4fa0) at /home/roc/rr/rr/src/preload/syscallbuf.c:3295
#4  syscall_hook (call=0x14f6e51d4fa0) at /home/roc/rr/rr/src/preload/syscallbuf.c:3329
#5  0x0000562c75e42e50 in _syscall_hook_trampoline () at /home/roc/rr/rr/src/preload/syscall_hook.S:313
#6  0x0000562c75e42eaf in __morestack () at /home/roc/rr/rr/src/preload/syscall_hook.S:458
#7  0x0000562c75e42f08 in _syscall_hook_trampoline_89_c2_f7_da () at /home/roc/rr/rr/src/preload/syscall_hook.S:504
#8  0x000014f6e62fef0c in __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
#9  0x0000562c76e70fe2 in my_write_core (sig=sig@entry=11) at /test/mtest/10.2_dbg/mysys/stacktrace.c:382
#10 0x0000562c767617b3 in handle_fatal_signal (sig=11) at /test/mtest/10.2_dbg/sql/signal_handler.cc:355
#11 <signal handler called>
#12 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#13 0x000045525f68ee95 in __vfprintf_internal (s=s@entry=0xfba38944550, format=0x562c770ec758 "Got error %d when trying to lock mutex %s at %s, line %d\n", ap=0xfba38946c10, mode_flags=<optimized out>) at vfprintf-internal.c:1688
#14 0x000045525f690022 in buffered_vfprintf (s=s@entry=0x45525f7ff5c0 <_IO_2_1_stderr_>, format=format@entry=0x562c770ec758 "Got error %d when trying to lock mutex %s at %s, line %d\n", args=args@entry=0xfba38946c10, mode_flags=mode_flags@entry=2) at vfprintf-internal.c:2377
#15 0x000045525f68cea4 in __vfprintf_internal (s=0x45525f7ff5c0 <_IO_2_1_stderr_>, format=0x562c770ec758 "Got error %d when trying to lock mutex %s at %s, line %d\n", ap=ap@entry=0xfba38946c10, mode_flags=mode_flags@entry=2) at vfprintf-internal.c:1346
#16 0x000045525f7441b3 in ___fprintf_chk (fp=<optimized out>, flag=flag@entry=1, format=format@entry=0x562c770ec758 "Got error %d when trying to lock mutex %s at %s, line %d\n") at fprintf_chk.c:33
#17 0x0000562c76e75c0a in fprintf (__fmt=0x562c770ec758 "Got error %d when trying to lock mutex %s at %s, line %d\n", __stream=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:100
#18 safe_mutex_lock (mp=mp@entry=0x14f6d00befb8, my_flags=my_flags@entry=0, file=file@entry=0x562c76f51548 "/test/mtest/10.2_dbg/sql/wsrep_thd.cc", line=line@entry=660) at /test/mtest/10.2_dbg/mysys/thr_mutex.c:296
#19 0x0000562c766f4f88 in inline_mysql_mutex_lock (src_line=660, src_file=0x562c76f51548 "/test/mtest/10.2_dbg/sql/wsrep_thd.cc", that=0x14f6d00befb8) at /test/mtest/10.2_dbg/include/mysql/psi/mysql_thread.h:673
#20 wsrep_rollback_process (thd=0x14f6e8001fe0) at /test/mtest/10.2_dbg/sql/wsrep_thd.cc:660
#21 0x0000562c766e51a9 in start_wsrep_THD (arg=0x562c793dc640) at /test/mtest/10.2_dbg/sql/wsrep_mysqld.cc:2169
#22 0x000014f6e62f6609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#23 0x000045525f735293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95



 Comments   
Comment by Jan Lindström (Inactive) [ 2022-01-04 ]

Can you retest this as rr trace does not work.

Comment by Sergei Golubchik [ 2022-02-07 ]

is it 10.2 only?

Comment by Ramesh Sivaraman [ 2022-02-07 ]

Currently this issue is only saw in 10.2

Comment by Elena Stepanova [ 2022-03-07 ]

The last 10.2 release is scheduled for less than 2 months from now. If it's a 10.2-only issue and can't even be reproduced so far, chances are it's not going to be fixed.

Generated at Thu Feb 08 09:44:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.