[MDEV-18314] mysqld got signal 11 Created: 2019-01-20  Updated: 2019-01-28  Resolved: 2019-01-28

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update
Affects Version/s: 10.3.12
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Arthur Borsboom Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback
Environment:

Arch Linux kernel 4.20.3 64-bit


 Description   

Reproducable crash on simple update statement:

update relations set owner_id='name1' where owner_id='name2';

Possible cause are the OS updates, of which the following (Arch Linux) packages have been recently updated.

  • adobe-source-serif-pro-fonts (2.007ro+1.007it-2 -> 2.010ro+1.010it-1)
  • poppler (0.72.0-1 -> 0.73.0-1)
  • cups-filters (1.21.6-1 -> 1.21.6-2)
  • poppler-glib (0.72.0-1 -> 0.73.0-1)
  • inkscape (0.92.4-1 -> 0.92.4-2)
  • jre-openjdk-headless (11.0.1.u13-2 -> 11.0.2.u7-1)
  • jre-openjdk (11.0.1.u13-2 -> 11.0.2.u7-1)
  • jdk-openjdk (11.0.1.u13-2 -> 11.0.2.u7-1)
  • jre8-openjdk-headless (8.u192-1 -> 8.u202-1)
  • jre8-openjdk (8.u192-1 -> 8.u202-1)
  • jdk8-openjdk (8.u192-1 -> 8.u202-1)
  • libreoffice-fresh (6.1.4-2 -> 6.1.4-3)
  • libsynctex (2018.48691-4 -> 2018.48691-5)
  • libuv (1.24.1-1 -> 1.25.0-1)
  • openjdk-doc (11.0.1.u13-2 -> 11.0.2.u7-1)
  • openjdk-src (11.0.1.u13-2 -> 11.0.2.u7-1)
  • openjdk8-doc (8.u192-1 -> 8.u202-1)
  • openjdk8-src (8.u192-1 -> 8.u202-1)
  • poppler-qt5 (0.72.0-1 -> 0.73.0-1)

Jan 20 21:36:50 z97 systemd[1]: Starting MariaDB 10.3.12 database server...
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] /usr/bin/mysqld (mysqld 10.3.12-MariaDB-log) starting as process 4740 ...
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Using Linux native AIO
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Uses event mutexes
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Number of pools: 1
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Using SSE2 crc32 instructions
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Completed initialization of buffer pool
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1115939382
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Last binlog file './mysql-bin.000726', position 545
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Creating shared tablespace for temporary tables
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Waiting for purge to start
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: 10.3.12 started; log sequence number 1115939391; transaction id 2366970
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] Recovering after a crash using mysql-bin
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] InnoDB: Buffer pool(s) load completed at 190120 21:36:51
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] Starting crash recovery...
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] Crash recovery finished.
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] Server socket created on IP: '::'.
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] Reading of all Master_info entries succeded
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] Added new Master_info '' to hash table
Jan 20 21:36:51 z97 mysqld[4740]: 2019-01-20 21:36:51 0 [Note] /usr/bin/mysqld: ready for connections.
Jan 20 21:36:51 z97 mysqld[4740]: Version: '10.3.12-MariaDB-log' socket: '/run/mysqld/mysqld.sock' port: 3306 Source distribution
Jan 20 21:36:51 z97 systemd[1]: Started MariaDB 10.3.12 database server.
Jan 20 21:39:29 z97 mysqld[4740]: 190120 21:39:29 [ERROR] mysqld got signal 11 ;
Jan 20 21:39:29 z97 mysqld[4740]: This could be because you hit a bug. It is also possible that this binary
Jan 20 21:39:29 z97 mysqld[4740]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 20 21:39:29 z97 mysqld[4740]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 20 21:39:29 z97 mysqld[4740]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Jan 20 21:39:29 z97 mysqld[4740]: We will try our best to scrape up some info that will hopefully help
Jan 20 21:39:29 z97 mysqld[4740]: diagnose the problem, but since we have already crashed,
Jan 20 21:39:29 z97 mysqld[4740]: something is definitely wrong and this may fail.
Jan 20 21:39:29 z97 mysqld[4740]: Server version: 10.3.12-MariaDB-log
Jan 20 21:39:29 z97 mysqld[4740]: key_buffer_size=16777216
Jan 20 21:39:29 z97 mysqld[4740]: read_buffer_size=262144
Jan 20 21:39:29 z97 mysqld[4740]: max_used_connections=21
Jan 20 21:39:29 z97 mysqld[4740]: max_threads=153
Jan 20 21:39:29 z97 mysqld[4740]: thread_count=28
Jan 20 21:39:29 z97 mysqld[4740]: It is possible that mysqld could use up to
Jan 20 21:39:29 z97 mysqld[4740]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 137277 K bytes of memory
Jan 20 21:39:29 z97 mysqld[4740]: Hope that's ok; if not, decrease some variables in the equation.
Jan 20 21:39:29 z97 mysqld[4740]: Thread pointer: 0x7f566a8810c8
Jan 20 21:39:29 z97 mysqld[4740]: Attempting backtrace. You can use the following information to find out
Jan 20 21:39:29 z97 mysqld[4740]: where mysqld died. If you see no messages after this, something went
Jan 20 21:39:29 z97 mysqld[4740]: terribly wrong...
Jan 20 21:39:29 z97 mysqld[4740]: stack_bottom = 0x7f566dbad5f8 thread_stack 0x49000

No errors in dmesg.

 Comments   
Comment by Arthur Borsboom [ 2019-01-20 ]

On another laptop (different hardware, but similar OS and setup), the same issue occurs.

There I did notice a crash message in dmesg, with a reference to glibc.

[ 277.948258] mysqld[2284]: segfault at 7fb157200000 ip 00007fb17f85d0c1 sp 00007fb17f4be418 error 6 in libc-2.28.so[7fb17f71f000+14b000]
[ 277.948264] Code: 01 00 00 48 83 fa 40 77 77 c5 fe 7f 44 17 e0 c5 fe 7f 07 c5 f8 77 c3 66 90 f3 0f 1e fa c5 f8 77 48 89 d1 40 0f b6 c6 48 89 fa <f3> aa 48 89 d0 c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 39 d1
[ 356.771429] traps: mysqld[3086] general protection fault ip:55d88d3c68d8 sp:7f8c5cbf94b0 error:0 in mysqld[55d88cdba000+7b5000]

Arch is using glib 2.28 at this moment.
Maybe, or better hopefully, this provides sufficient information to find the cause.

Comment by Elena Stepanova [ 2019-01-21 ]

If it's reproducible, would you be able to provide a complete test case? (Data dump on which the provided query crashes, and configuration file(s)).

Comment by Arthur Borsboom [ 2019-01-21 ]

The crash is reproducible, but the database contains commercial sensitive information, which I cannot share.

On one of the two systems, I have deleted the database with the issue and recreated it from a SQL script. This workaround succeeded.

Is there something else I can do to provide the information, without sharing the content of the database?
If not, we close the issue and I will use the workaround.

Comment by Elena Stepanova [ 2019-01-21 ]

If restoring from SQL script makes the problem go away, how was it reproduced on the 2nd laptop? Did you copy over the data files themselves?

If the binary data files are important for the problem, it might be that they are corrupted in some way. If you didn't run CHECK TABLE and CHECK TABLE .. EXTENDED, please do. If the table is InnoDB, then also innochecksum might be useful.

Can you provide the table structure itself? 

SHOW CREATE TABLE relations;
 
SHOW INDEX IN relations;

It shouldn't be too sensitive, but if it is, you can obfuscate column names, as long as the obfuscated ones are kept consistent with the query.

Comment by Arthur Borsboom [ 2019-01-24 ]

I am guessing, that the corruption happened the following way.

MariaDB upgrade 10.1 -> 10.3 by automatic updates of the OS (Arch Linux).
Continue using the databases without upgrading the schema by the mysql_upgrade script.
Run the mysql_upgrade, after noticing the warnings in the journal.

Check, optimize and repair tables don't seem to fix the problem.

The table structure itself is not sensitive, so here are the two results.

CREATE TABLE `relations` (
 
  `uid` int(11) NOT NULL AUTO_INCREMENT,
 
  `project_uid` int(11) NOT NULL,
 
  `activity_id` varchar(20) GENERATED ALWAYS AS (concat(`Werkpakket`,'-',`IitemID`,'-',`PredID`)) VIRTUAL,
 
  `owner_id` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL,
 
  `Werkpakket` char(10) COLLATE utf8mb4_unicode_ci NOT NULL,
 
  `IrelateID` mediumint(9) DEFAULT NULL,
 
  `Taskid` char(10) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 
  `PredID` char(4) COLLATE utf8mb4_unicode_ci NOT NULL,
 
  `RelLag` int(4) DEFAULT NULL,
 
  `RelType` char(2) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 
  `SuccID` char(4) COLLATE utf8mb4_unicode_ci NOT NULL,
 
  `Tcreated` datetime DEFAULT NULL,
 
  `CcreatedBy` char(20) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 
  `IitemID` mediumint(4) NOT NULL,
 
  `Linclude` tinyint(4) DEFAULT NULL,
 
  `Lstandard` tinyint(4) DEFAULT NULL,
 
  `Lappended` tinyint(4) DEFAULT NULL,
 
  `RelationshipNotes` char(100) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 
  PRIMARY KEY (`uid`),
 
  KEY `project_constraint_2` (`project_uid`),
 
  CONSTRAINT `project_constraint_2` FOREIGN KEY (`project_uid`) REFERENCES `projects` (`uid`)
 
) ENGINE=InnoDB AUTO_INCREMENT=269290 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci 


MariaDB [tasys]> SHOW INDEX IN relations;
 
+-----------+------------+----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
 
| Table     | Non_unique | Key_name             | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
 
+-----------+------------+----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
 
| relations |          0 | PRIMARY              |            1 | uid         | A         |       12878 |     NULL | NULL   |      | BTREE      |         |               |
 
| relations |          1 | project_constraint_2 |            1 | project_uid | A         |          10 |     NULL | NULL   |      | BTREE      |         |               |
 
+-----------+------------+----------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

Does this help anything to improve the MariaDB product?

Comment by Elena Stepanova [ 2019-01-24 ]

Thanks.
Could you please add to it the output of show table status like 'relations'?
When you say that CHECK etc. didn't fix the problem, does it mean that CHECK has shown that something is wrong with the table?
Are you always getting the same truncated stack trace on all machines where it's reproducible? Can you enable a coredump and see if you can get a stack trace from it?
Please also paste or attach your cnf file(s).

Comment by Arthur Borsboom [ 2019-01-25 ]

Check does not fix the problem because the engine type is not supported for repair.

...
 
tasys.relations
 
note     : The storage engine for the table doesn't support repair
 
...

The status of the relations table:

MariaDB [tasys]> show table status like 'relations';
 
+-----------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+------------------+-----------+
 
| Name      | Engine | Version | Row_format | Rows  | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation          | Checksum | Create_options | Comment | Max_index_length | Temporary |
 
+-----------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+------------------+-----------+
 
| relations | InnoDB |      11 | Dynamic    | 12878 |            286 |     3686400 |               0 |       196608 |   2097152 |         269290 | 2019-01-20 22:37:30 | NULL        | NULL       | utf8mb4_unicode_ci |     NULL |                |         |                0 | N         |
 
+-----------+--------+---------+------------+-------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+------------------+-----------+

Currently I have only one machine left, where this issue is reproducible (I applied a workaround to the other machine). The stacktrace is always the same (and limited). I have tried to enable the core dump (and maybe I have) and reproduced the crash, but I could not find a core file somewhere on the system.

I added this to my.cnf under section [mysqld]

stack-trace
 
core-file
 
disable-gdb

I restarted MariaDB and verified the setting.

MariaDB [tasys]> SHOW GLOBAL VARIABLES LIKE 'core_file';
 
+---------------+-------+
 
| Variable_name | Value |
 
+---------------+-------+
 
| core_file     | ON    |
 
+---------------+-------+
 
1 row in set (0.001 sec)

I executed the following.

[root@pb450 arthur]# mkdir /tmp/corefiles
 
[root@pb450 arthur]# chmod 777 /tmp/corefiles
 
[root@pb450 arthur]# echo "/tmp/corefiles/core" > /proc/sys/kernel/core_pattern
 
[root@pb450 arthur]# echo "1" > /proc/sys/kernel/core_uses_pid

I executed the update query and it crashed, with the following as a result.

[root@pb450 corefiles]# systemctl status mariadb -n1000
 
● mariadb.service - MariaDB 10.3.12 database server
 
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
 
   Active: active (running) since Fri 2019-01-25 10:59:07 CET; 4min 18s ago
 
     Docs: man:mysqld(8)
 
           https://mariadb.com/kb/en/library/systemd/
 
  Process: 3159 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 
  Process: 3160 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_STA>
 
  Process: 3256 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
 
 Main PID: 3224 (mysqld)
 
   Status: "Taking your SQL requests now..."
 
    Tasks: 32 (limit: 4915)
 
   Memory: 100.7M
 
   CGroup: /system.slice/mariadb.service
 
           └─3224 /usr/bin/mysqld
 
 
 
Jan 25 10:59:06 pb450 systemd[1]: Starting MariaDB 10.3.12 database server...
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] /usr/bin/mysqld (mysqld 10.3.12-MariaDB-log) starting as process 3224 ...
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Using Linux native AIO
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Uses event mutexes
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Number of pools: 1
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Using SSE2 crc32 instructions
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Completed initialization of buffer pool
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man>
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Creating shared tablespace for temporary tables
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Waiting for purge to start
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: 10.3.12 started; log sequence number 1249020049; transaction id 3546358
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] Server socket created on IP: '::'.
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] InnoDB: Buffer pool(s) load completed at 190125 10:59:07
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] Reading of all Master_info entries succeded
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] Added new Master_info '' to hash table
 
Jan 25 10:59:07 pb450 mysqld[3224]: 2019-01-25 10:59:07 0 [Note] /usr/bin/mysqld: ready for connections.
 
Jan 25 10:59:07 pb450 mysqld[3224]: Version: '10.3.12-MariaDB-log'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Source distribution
 
Jan 25 10:59:07 pb450 systemd[1]: Started MariaDB 10.3.12 database server.
 
Jan 25 11:02:29 pb450 mysqld[3224]: 190125 11:02:29 [ERROR] mysqld got signal 11 ;
 
Jan 25 11:02:29 pb450 mysqld[3224]: This could be because you hit a bug. It is also possible that this binary
 
Jan 25 11:02:29 pb450 mysqld[3224]: or one of the libraries it was linked against is corrupt, improperly built,
 
Jan 25 11:02:29 pb450 mysqld[3224]: or misconfigured. This error can also be caused by malfunctioning hardware.
 
Jan 25 11:02:29 pb450 mysqld[3224]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
Jan 25 11:02:29 pb450 mysqld[3224]: We will try our best to scrape up some info that will hopefully help
 
Jan 25 11:02:29 pb450 mysqld[3224]: diagnose the problem, but since we have already crashed,
 
Jan 25 11:02:29 pb450 mysqld[3224]: something is definitely wrong and this may fail.
 
Jan 25 11:02:29 pb450 mysqld[3224]: Server version: 10.3.12-MariaDB-log
 
Jan 25 11:02:29 pb450 mysqld[3224]: key_buffer_size=16777216
 
Jan 25 11:02:29 pb450 mysqld[3224]: read_buffer_size=262144
 
Jan 25 11:02:29 pb450 mysqld[3224]: max_used_connections=1
 
Jan 25 11:02:29 pb450 mysqld[3224]: max_threads=22
 
Jan 25 11:02:29 pb450 mysqld[3224]: thread_count=8
 
Jan 25 11:02:29 pb450 mysqld[3224]: It is possible that mysqld could use up to
 
Jan 25 11:02:29 pb450 mysqld[3224]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 33748 K  bytes of memory
 
Jan 25 11:02:29 pb450 mysqld[3224]: Hope that's ok; if not, decrease some variables in the equation.
 
Jan 25 11:02:29 pb450 mysqld[3224]: Thread pointer: 0x7f3dcca07f48
 
Jan 25 11:02:29 pb450 mysqld[3224]: Attempting backtrace. You can use the following information to find out
 
Jan 25 11:02:29 pb450 mysqld[3224]: where mysqld died. If you see no messages after this, something went
 
Jan 25 11:02:29 pb450 mysqld[3224]: terribly wrong...
 
Jan 25 11:02:29 pb450 mysqld[3224]: stack_bottom = 0x7f3df68fd5f8 thread_stack 0x49000


[root@pb450 corefiles]# coredumpctl list
 
TIME                            PID   UID   GID SIG COREFILE  EXE
 
Sun 2019-01-20 22:33:41 CET    2222    89    89  11 missing   /usr/bin/mysqld
 
Sun 2019-01-20 22:35:00 CET    3062    89    89  11 missing   /usr/bin/mysqld


[root@pb450 corefiles]# ls -al
 
total 0
 
drwxrwxrwx  2 root root  40 Jan 25 11:01 .
 
drwxrwxrwt 18 root root 520 Jan 25 11:01 ..

Did I do something wrong, or does MariaDB crash in a way that the core dump is not written?

Comment by Elena Stepanova [ 2019-01-28 ]

ArthurBorsboom,

Did you check ulimit -c and systemd settings? I don't see ArchLinux packages among ours, so it must be packaged by the distribution maintainers. Can it be that it overrides the settings / disables the coredump?

Regarding CHECK/REPAIR TABLE, I understand why REPAIR wouldn't do anything, but does CHECK show any problems?

Comment by Arthur Borsboom [ 2019-01-28 ]

Hi Elena,

I needed my database to be available today, so I have dropped the damaged database and restored an old one.
If this is an issue to find the cause, I suggest we close the ticket.

I recall check did not show any problems.

Comment by Elena Stepanova [ 2019-01-28 ]

ArthurBorsboom,

I see. Yes, unfortunately without the stack trace we don't even know which direction to look, it can be anything. I'll close it for now, if you experience the problem again, please comment and we'll re-open the report.

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