Date: Fri, 20 Aug 2021 03:35:48 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 257958] databases/mariadb103-server: mysqld got signal 6: Failing assertion: page_is_comp(next_page) == page_is_comp(page) Message-ID: <bug-257958-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257958 Bug ID: 257958 Summary: databases/mariadb103-server: mysqld got signal 6: Failing assertion: page_is_comp(next_page) =3D=3D page_is_comp(page) Product: Ports & Packages Version: Latest Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: brnrd@freebsd.org Reporter: iron.udjin@gmail.com Flags: maintainer-feedback?(brnrd@freebsd.org) Assignee: brnrd@freebsd.org Hello, OS: 13.0-STABLE stable/13-n246859-416194c9af84 mariadb103-server-10.3.31 MariaDB crashing when tries to access one of the DB tables: 2021-08-20 06:14:01 0x1681847a00 InnoDB: Assertion failure in file /usr/ports/databases/mariadb103-server/work/mariadb-10.3.31/storage/innobas= e/btr/btr0pcur.cc line 527 InnoDB: Failing assertion: page_is_comp(next_page) =3D=3D 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,=20 something is definitely wrong and this may fail. Server version: 10.3.31-MariaDB-log key_buffer_size=3D17179869184 read_buffer_size=3D262144 max_used_connections=3D8 max_threads=3D65537 thread_count=3D13 It is possible that mysqld could use up to=20 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =3D 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 =3D 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 `wp_aiowps_failed_logins` Connection ID (thread ID): 38 Status: NOT_KILLED Optimizer switch: index_merge=3Don,index_merge_union=3Don,index_merge_sort_union=3Don,index_m= erge_intersection=3Don,index_merge_sort_intersection=3Doff,engine_condition= _pushdown=3Doff,index_condition_pushdown=3Don,derived_merge=3Don,derived_wi= th_keys=3Don,firstmatch=3Don,loosescan=3Don,materialization=3Don,in_to_exis= ts=3Don,semijoin=3Don,partial_match_rowid_merge=3Don,partial_match_table_sc= an=3Don,subquery_cache=3Don,mrr=3Doff,mrr_cost_based=3Doff,mrr_sort_keys=3D= off,outer_join_with_cache=3Don,semijoin_with_cache=3Don,join_cache_incremen= tal=3Don,join_cache_hashed=3Don,join_cache_bka=3Don,optimize_join_buffer_si= ze=3Doff,table_elimination=3Don,extended_keys=3Don,exists_to_in=3Don,orderb= y_uses_equalities=3Don,condition_pushdown_for_derived=3Don,split_materializ= ed=3Don ----------------------------------------------- Here is .core backtrace: Core was generated by `/usr/local/libexec/mysqld --defaults-extra-file=3D/var/db/mysql/my.cnf --basedir=3D/'. 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=3Dactp@entry=3D0x7fffdbbbce40, sig=3Dsig@entry=3D6, info=3Dinfo@entry=3D0x7fffdbbbd230, ucp=3Ducp@entry=3D= 0x7fffdbbbcec0) at /usr/src/lib/libthr/thread/thr_sig.c:303 #3 0x000000080181236e in thr_sighandler (sig=3D6, info=3D0x7fffdbbbd230, _ucp=3D0x7fffdbbbcec0) 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=3Ds@entry=3D6) at /usr/src/lib/libc/gen/raise.c:52 #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_sta= te*, 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=3D0x1681847a00) at /usr/src/lib/libthr/thread/thr_create.c:292 #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/ ? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257958-7788>