[Bug 257958] databases/mariadb103-server: mysqld got signal 6: Failing assertion: page_is_comp(next_page) == page_is_comp(page)

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 20 Aug 2021 03:35:48 +0000

            Bug ID: 257958
           Summary: databases/mariadb103-server: mysqld got signal 6:
                    Failing assertion: page_is_comp(next_page) ==
           Product: Ports & Packages
           Version: Latest
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: brnrd_at_freebsd.org
          Reporter: iron.udjin_at_gmail.com
             Flags: maintainer-feedback?(brnrd_at_freebsd.org)
          Assignee: brnrd_at_freebsd.org


OS: 13.0-STABLE stable/13-n246859-416194c9af84

MariaDB crashing when tries to access one of the DB tables:

2021-08-20 06:14:01 0x1681847a00  InnoDB: Assertion failure in file
line 527
InnoDB: Failing assertion: page_is_comp(next_page) == page_is_comp(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
210820  6:14:01 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.3.31-MariaDB-log
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
2181073303 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1857a95848
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fffdbbbfeb0 thread_stack 0x49000
0x115139c <my_print_stacktrace+0x3c> at /usr/local/libexec/mysqld
0xb32ec9 <handle_fatal_signal+0x299> at /usr/local/libexec/mysqld
0x801812e62 <pthread_sigmask+0x532> at /lib/libthr.so.3

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x1857ab4520): SELECT /*!40001 SQL_NO_CACHE */ `id`, `user_id`,
`user_login`, `failed_login_date`, `login_attempt_ip` FROM

Connection ID (thread ID): 38

Optimizer switch:


Here is .core backtrace:

Core was generated by `/usr/local/libexec/mysqld
--defaults-extra-file=/var/db/mysql/my.cnf --basedir=/'.
Program terminated with signal SIGABRT, Aborted.
#0  kill () at kill.S:4
4       RSYSCALL(kill)
[Current thread is 1 (LWP 181500)]
#0  kill () at kill.S:4
#1  0x0000000000b330ea in handle_fatal_signal ()
#2  0x0000000801812e62 in handle_signal (actp=actp_at_entry=0x7fffdbbbce40,
sig=sig_at_entry=6, info=info_at_entry=0x7fffdbbbd230, ucp=ucp_at_entry=0x7fffdbbbcec0)
at /usr/src/lib/libthr/thread/thr_sig.c:303
#3  0x000000080181236e in thr_sighandler (sig=6, info=0x7fffdbbbd230,
_ucp=0x7fffdbbbcec0) at /usr/src/lib/libthr/thread/thr_sig.c:246
#4  <signal handler called>
#5  thr_kill () at thr_kill.S:4
#6  0x00000008018d5f84 in __raise (s=s_at_entry=6) at
#7  0x000000080198cc89 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#8  0x0000000001027c7b in ?? ()
#9  0x0000000000efaf0c in ?? ()
#10 0x0000000000fd4912 in ?? ()
#11 0x0000000000e2b7b3 in ?? ()
#12 0x0000000000a2bdf2 in handler::ha_rnd_next(unsigned char*) ()
#13 0x0000000000b5cb1a in rr_sequential(READ_RECORD*) ()
#14 0x0000000000c83cdc in sub_select(JOIN*, st_join_table*, bool) ()
#15 0x0000000000c70f62 in JOIN::exec_inner() ()
#16 0x0000000000c582f5 in mysql_select(THD*, TABLE_LIST*, unsigned int,
List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*,
unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) ()
#17 0x0000000000c57fc9 in handle_select(THD*, LEX*, select_result*, unsigned
long) ()
#18 0x0000000000c294b3 in ?? ()
#19 0x0000000000c23afb in mysql_execute_command(THD*) ()
#20 0x0000000000c213d3 in mysql_parse(THD*, char*, unsigned int, Parser_state*,
bool, bool) ()
#21 0x0000000000c1ea69 in dispatch_command(enum_server_command, THD*, char*,
unsigned int, bool, bool) ()
#22 0x0000000000c20b05 in do_command(THD*) ()
#23 0x0000000000d81184 in tp_callback(TP_connection*) ()
#24 0x0000000000e16dc0 in ?? ()
#25 0x0000000801809768 in thread_start (curthread=0x1681847a00) at
#26 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdbbc0000

I don't know is it a problem with OS or mariadb.

Should I report this bug to https://jira.mariadb.org/ ?

You are receiving this mail because:
You are the assignee for the bug.
Received on Fri Aug 20 2021 - 03:35:48 UTC

Original text of this message