[MDEV-9977] Crash when accessing large (>4G) InnoDB table on MariaDB 10.1.x 32-bit binaries Created: 2016-04-25  Updated: 2018-07-23  Resolved: 2018-01-08

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.1.10, 10.1.13
Fix Version/s: 10.0.25

Type: Bug Priority: Critical
Reporter: Valerii Kravchuk Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: innodb, regression
Environment:

Windows OS, 64 bit, but using 32-bit Windows binaries from MariaDB
CentOS 6.7 32-bit with 32-bit binaries from MariaDB


Issue Links:
Relates
relates to MDEV-14887 On a 32-bit system, MariaDB 10.2 mish... Closed
Sprint: 10.1.14

 Description   

I've installed32-bit Windows binaries of MariaDB 10.1.13 on my 64-bit Windows XP from this URL:

http://mariadb.mirror.serveriai.lt//mariadb-10.1.13/win32-packages/mariadb-10.1.13-win32.msi

Installation was without problems, I've used all defaults but 512M of buffer pool, my.ini is the following:

[mysqld]
 
datadir=C:/Program Files (x86)/MariaDB 10.1/data
 
port=3316
 
sql_mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
 
default_storage_engine=innodb
 
innodb_buffer_pool_size=512M
 
innodb_log_file_size=50M
 
[client]
 
port=3316

Then I've created InnoDB table tinno in the test database like this:

create table tinno(id int auto_increment primary key, c1 varchar(2000)) engine=InnoDB;

Note that latin1 character set was used by default. I've inserted one row into the table:

insert into tinno(c1) values(repeat('a',2000));

and then executed the following many times:

insert into tinno(c1) select repeat('b',2000) from tinno;

until the table .ibd file on disk became larger than 4G:

C:\...les (x86)\MariaDB 10.1\data\test>dir
 
 Volume in drive C has no label.
 
 Volume Serial Number is 98B6-4277
 
 
 
 Directory of C:\Program Files (x86)\MariaDB 10.1\data\test
 
 
 
22.04.2016  15:00    <DIR>          .
 
22.04.2016  15:00    <DIR>          ..
 
22.04.2016  15:00             2 944 tinno.frm
 
22.04.2016  15:23     4 991 221 760 tinno.ibd
 
               2 File(s)  4 991 224 704 bytes
 
               2 Dir(s)  59 627 225 088 bytes free

Then I checked that I can select some rows from the table (with select * from tinno limit 100 etc), can apply SHOW CREATE TABLE and SHOW TABLE STATUS - everything worked well. I shut the box down cleanly and then started it today and tried to execture the following:

C:\Program Files (x86)\MariaDB 10.1\bin>mysql -uroot -proot -P3316 test
 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
 
Your MariaDB connection id is 2
 
Server version: 10.1.13-MariaDB mariadb.org binary distribution
 
 
 
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
 
 
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
 
 
MariaDB [test]> show tables;
 
+----------------+
 
| Tables_in_test |
 
+----------------+
 
| tinno          |
 
+----------------+
 
1 row in set (0.05 sec)
 
 
 
MariaDB [test]> show table status like 'tinno'\G
 
ERROR 2013 (HY000): Lost connection to MySQL server during query
 
MariaDB [test]> exit

Server crashed and this is what I had in the error log:

...
 
2016-04-22 14:57:54 4084 [Note] C:\Program Files (x86)\MariaDB 10.1\bin\mysqld.exe: ready for connections.
 
Version: '10.1.13-MariaDB'  socket: ''  port: 3316  mariadb.org binary distribution
 
2016-04-22 15:28:27 3428 [Note] C:\Program Files (x86)\MariaDB 10.1\bin\mysqld.exe: Normal shutdown
 
 
 
2016-04-22 15:28:28 3428 [Note] Event Scheduler: Purging the queue. 0 events
 
2016-04-22 15:28:28 2252 [Note] InnoDB: FTS optimize thread exiting.
 
2016-04-22 15:28:28 3428 [Note] InnoDB: Starting shutdown...
 
2016-04-22 15:28:32 3428 [Note] InnoDB: Shutdown completed; log sequence number 4486310509
 
2016-04-22 15:28:32 3428 [Note] C:\Program Files (x86)\MariaDB 10.1\bin\mysqld.exe: Shutdown complete
 
 
 
2016-04-25 10:32:09 1856 [Note] InnoDB: Using mutexes to ref count buffer pool pages
 
2016-04-25 10:32:09 1856 [Note] InnoDB: The InnoDB memory heap is disabled
 
2016-04-25 10:32:09 1856 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
 
2016-04-25 10:32:09 1856 [Note] InnoDB: Memory barrier is not used
 
2016-04-25 10:32:09 1856 [Note] InnoDB: Compressed tables use zlib 1.2.3
 
2016-04-25 10:32:11 1856 [Note] InnoDB: Using generic crc32 instructions
 
2016-04-25 10:32:11 1856 [Note] InnoDB: Initializing buffer pool, size = 512.0M
 
2016-04-25 10:32:12 1856 [Note] InnoDB: Completed initialization of buffer pool
 
2016-04-25 10:32:19 1856 [Note] InnoDB: Highest supported file format is Barracuda.
 
2016-04-25 10:32:27 1856 [Note] InnoDB: 128 rollback segment(s) are active.
 
2016-04-25 10:32:27 1856 [Note] InnoDB: Waiting for purge to start
 
2016-04-25 10:32:27 1856 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 4486310509
 
2016-04-25 10:32:28 2516 [Note] InnoDB: Dumping buffer pool(s) not yet started
 
2016-04-25 10:32:30 1856 [Note] Plugin 'FEEDBACK' is disabled.
 
2016-04-25 10:32:32 1856 [Note] Server socket created on IP: '0.0.0.0'.
 
2016-04-25 10:32:38 1856 [Note] C:\Program Files (x86)\MariaDB 10.1\bin\mysqld.exe: ready for connections.
 
Version: '10.1.13-MariaDB'  socket: ''  port: 3316  mariadb.org binary distribution
 
InnoDB: Error: trying to access page number 207980 in space 4,
 
InnoDB: space name test/tinno,
 
InnoDB: which is outside the tablespace bounds.
 
InnoDB: Byte offset 0, len 16384, i/o type 10.
 
InnoDB: If you get this error at mysqld startup, please check that
 
InnoDB: your my.cnf matches the ibdata files that you have in the
 
InnoDB: MySQL server.
 
2016-04-25 12:33:44 1278  InnoDB: Assertion failure in thread 4728 in file fil0fil.cc line 5866
 
InnoDB: We intentionally generate a memory trap.
 
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
 
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: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
 
InnoDB: about forcing recovery.
 
160425 12:33:44 [ERROR] mysqld got exception 0x80000003 ;
 
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.1.13-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=1
 
max_threads=153
 
thread_count=1
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 465948 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x2b867010
 
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...
 
mysqld.exe!my_parameter_handler()[my_init.c:256]
 
mysqld.exe!raise()[winsig.c:586]
 
mysqld.exe!abort()[abort.c:74]
 
mysqld.exe!_fil_io()[fil0fil.cc:5866]
 
mysqld.exe!buf_read_page_low()[buf0rea.cc:243]
 
mysqld.exe!buf_read_page()[buf0rea.cc:474]
 
mysqld.exe!buf_page_get_gen()[buf0buf.cc:2942]
 
mysqld.exe!btr_cur_open_at_index_side_func()[btr0cur.cc:991]
 
mysqld.exe!row_search_get_max_rec()[row0sel.cc:5442]
 
mysqld.exe!row_search_max_autoinc()[row0sel.cc:5487]
 
mysqld.exe!ha_innobase::innobase_initialize_autoinc()[ha_innodb.cc:5916]
 
mysqld.exe!ha_innobase::open()[ha_innodb.cc:6406]
 
mysqld.exe!handler::ha_open()[handler.cc:2500]
 
mysqld.exe!open_table_from_share()[table.cc:2927]
 
mysqld.exe!open_table()[sql_base.cc:2563]
 
mysqld.exe!open_and_process_table()[sql_base.cc:4073]
 
mysqld.exe!open_tables()[sql_base.cc:4584]
 
mysqld.exe!open_normal_and_derived_tables()[sql_base.cc:5310]
 
mysqld.exe!fill_schema_table_by_open()[sql_show.cc:4156]
 
mysqld.exe!get_all_tables()[sql_show.cc:4785]
 
mysqld.exe!get_schema_tables_result()[sql_show.cc:8114]
 
mysqld.exe!JOIN::exec_inner()[sql_select.cc:2670]
 
mysqld.exe!JOIN::exec()[sql_select.cc:2519]
 
mysqld.exe!mysql_select()[sql_select.cc:3453]
 
mysqld.exe!handle_select()[sql_select.cc:384]
 
mysqld.exe!execute_sqlcom_select()[sql_parse.cc:5904]
 
mysqld.exe!mysql_execute_command()[sql_parse.cc:2960]
 
mysqld.exe!mysql_parse()[sql_parse.cc:7304]
 
mysqld.exe!dispatch_command()[sql_parse.cc:1489]
 
mysqld.exe!do_command()[sql_parse.cc:1141]
 
mysqld.exe!do_handle_one_connection()[sql_connect.cc:1349]
 
mysqld.exe!handle_one_connection()[sql_connect.cc:1261]
 
mysqld.exe!pthread_start()[my_winthread.c:60]
 
mysqld.exe!_callthreadstartex()[threadex.c:314]
 
mysqld.exe!_threadstartex()[threadex.c:292]
 
kernel32.dll!FlsSetValue()
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x2b873180): show table status like 'tinno'
 
Connection ID (thread ID): 2
 
Status: NOT_KILLED
 
...

Same crash happened when I executed SHOW CREATE TABLE after restart:

...
 
2016-04-25 12:47:29 5104 [Note] InnoDB: from the doublewrite buffer...
 
2016-04-25 12:47:30 5104 [Warning] InnoDB: A page in the doublewrite buffer is not within space bounds; space id 4 page number 301007, page 1 in doublewrite buf.
 
2016-04-25 12:47:30 5104 [Warning] InnoDB: A page in the doublewrite buffer is not within space bounds; space id 4 page number 301008, page 2 in doublewrite buf.
 
...
 
2016-04-25 12:47:30 5104 [Warning] InnoDB: A page in the doublewrite buffer is not within space bounds; space id 4 page number 250463, page 100 in doublewrite buf.
 
2016-04-25 12:47:31 5104 [Note] InnoDB: 128 rollback segment(s) are active.
 
2016-04-25 12:47:31 5104 [Note] InnoDB: Waiting for purge to start
 
2016-04-25 12:47:31 5104 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 4486310519
 
2016-04-25 12:47:31 2244 [Note] InnoDB: Dumping buffer pool(s) not yet started
 
2016-04-25 12:47:31 5104 [Note] Plugin 'FEEDBACK' is disabled.
 
2016-04-25 12:47:31 5104 [Note] Server socket created on IP: '0.0.0.0'.
 
2016-04-25 12:47:31 5104 [Note] C:\Program Files (x86)\MariaDB 10.1\bin\mysqld.exe: ready for connections.
 
Version: '10.1.13-MariaDB'  socket: ''  port: 3316  mariadb.org binary distribution
 
InnoDB: Error: trying to access page number 207980 in space 4,
 
InnoDB: space name test/tinno,
 
InnoDB: which is outside the tablespace bounds.
 
InnoDB: Byte offset 0, len 16384, i/o type 10.
 
InnoDB: If you get this error at mysqld startup, please check that
 
InnoDB: your my.cnf matches the ibdata files that you have in the
 
InnoDB: MySQL server.
 
2016-04-25 12:47:52 55c  InnoDB: Assertion failure in thread 1372 in file fil0fil.cc line 5866
 
InnoDB: We intentionally generate a memory trap.
 
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
 
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: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
 
InnoDB: about forcing recovery.
 
160425 12:47:52 [ERROR] mysqld got exception 0x80000003 ;
 
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.1.13-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=1
 
max_threads=153
 
thread_count=1
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 465948 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x2b724ff8
 
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...
 
mysqld.exe!my_parameter_handler()[my_init.c:256]
 
mysqld.exe!raise()[winsig.c:586]
 
mysqld.exe!abort()[abort.c:74]
 
mysqld.exe!_fil_io()[fil0fil.cc:5866]
 
mysqld.exe!buf_read_page_low()[buf0rea.cc:243]
 
mysqld.exe!buf_read_page()[buf0rea.cc:474]
 
mysqld.exe!buf_page_get_gen()[buf0buf.cc:2942]
 
mysqld.exe!btr_cur_open_at_index_side_func()[btr0cur.cc:991]
 
mysqld.exe!row_search_get_max_rec()[row0sel.cc:5442]
 
mysqld.exe!row_search_max_autoinc()[row0sel.cc:5487]
 
mysqld.exe!ha_innobase::innobase_initialize_autoinc()[ha_innodb.cc:5916]
 
mysqld.exe!ha_innobase::open()[ha_innodb.cc:6406]
 
mysqld.exe!handler::ha_open()[handler.cc:2500]
 
mysqld.exe!open_table_from_share()[table.cc:2927]
 
mysqld.exe!open_table()[sql_base.cc:2563]
 
mysqld.exe!open_and_process_table()[sql_base.cc:4073]
 
mysqld.exe!open_tables()[sql_base.cc:4584]
 
mysqld.exe!mysqld_show_create_get_fields()[sql_show.cc:1134]
 
mysqld.exe!mysqld_show_create()[sql_show.cc:1228]
 
mysqld.exe!mysql_execute_command()[sql_parse.cc:3699]
 
mysqld.exe!mysql_parse()[sql_parse.cc:7304]
 
mysqld.exe!dispatch_command()[sql_parse.cc:1489]
 
mysqld.exe!do_command()[sql_parse.cc:1141]
 
mysqld.exe!do_handle_one_connection()[sql_connect.cc:1349]
 
mysqld.exe!handle_one_connection()[sql_connect.cc:1261]
 
mysqld.exe!pthread_start()[my_winthread.c:60]
 
mysqld.exe!_callthreadstartex()[threadex.c:314]
 
mysqld.exe!_threadstartex()[threadex.c:292]
 
kernel32.dll!FlsSetValue()
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x2b827030): show create table tinno
 
Connection ID (thread ID): 2
 
Status: NOT_KILLED

According to other rteporters this happened with 10.1.10 as well, but never with older 5.5.x or 10.0.x and never with 64-bit MariaDB.

 Comments   
Comment by Valerii Kravchuk [ 2016-04-25 ]

Same crash is repeatable with the same steps (server restart is required) with 10.1.13 32-bit binaries on CentOS 6.7:

[openxs@centos64i386 mariadb-10.1.13-linux-i686]$ uname -a
 
Linux centos64i386 2.6.32-573.8.1.el6.i686 #1 SMP Tue Nov 10 14:58:44 UTC 2015 i686 i686 i386 GNU/Linux
 
[openxs@centos64i386 mariadb-10.1.13-linux-i686]$ cat /etc/issue
 
CentOS release 6.7 (Final)
 
Kernel \r on an \m

After creating the same table with 4G+ of data that worked OK:

...
 
MariaDB [test]> insert into tinno(c1) select repeat('b',2000) from tinno;
 
Query OK, 1048576 rows affected (9 min 39.88 sec)
 
Records: 1048576  Duplicates: 0  Warnings: 0
 
 
 
MariaDB [test]> show table status like 'tinno'\G
 
*************************** 1. row ***************************
 
           Name: tinno
 
         Engine: InnoDB
 
        Version: 10
 
     Row_format: Compact
 
           Rows: 1801951
 
 Avg_row_length: 2686
 
    Data_length: 4841275392
 
Max_data_length: 0
 
   Index_length: 0
 
      Data_free: 6291456
 
 Auto_increment: 2490316
 
    Create_time: 2016-04-25 18:48:54
 
    Update_time: NULL
 
     Check_time: NULL
 
      Collation: latin1_swedish_ci
 
       Checksum: NULL
 
 Create_options:
 
        Comment:
 
1 row in set (0.44 sec)
 
 
 
MariaDB [test]> select count(*) from tinno;
 
+----------+
 
| count(*) |
 
+----------+
 
|  2097152 |
 
+----------+
 
1 row in set (3 min 6.09 sec)

I've restarted server and got similar warnings about doublewrite buffer pages upon startup and then:

[openxs@centos64i386 mariadb-10.1.13-linux-i686]$ bin/mysql -uroot
 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
 
Your MariaDB connection id is 2
 
Server version: 10.1.13-MariaDB MariaDB Server
 
 
 
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
 
 
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
 
 
MariaDB [(none)]> show create table test.tinno\G
 
ERROR 2013 (HY000): Lost connection to MySQL server during query
 
MariaDB [(none)]> 160425 19:26:22 mysqld_safe Number of processes running now: 0
 
160425 19:26:22 mysqld_safe mysqld restarted
 
 
 
MariaDB [(none)]> exit
 
Bye

In the error log I see:

...
 
2016-04-25 19:17:05 3078064688 [Note] /home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld: ready for connections.
 
Version: '10.1.13-MariaDB'  socket: '/tmp/mysql.sock'  port: 3306  MariaDB Server
 
InnoDB: Error: trying to access page number 207980 in space 4,
 
InnoDB: space name test/tinno,
 
InnoDB: which is outside the tablespace bounds.
 
InnoDB: Byte offset 0, len 16384, i/o type 10.
 
InnoDB: If you get this error at mysqld startup, please check that
 
InnoDB: your my.cnf matches the ibdata files that you have in the
 
InnoDB: MySQL server.
 
2016-04-25 19:26:21 839a2f70  InnoDB: Assertion failure in thread 2207919984 in file fil0fil.cc line 5866
 
InnoDB: We intentionally generate a memory trap.
 
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
 
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: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
 
InnoDB: about forcing recovery.
 
160425 19:26:21 [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.1.13-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=1
 
max_threads=153
 
thread_count=1
 
It is possible that mysqld could use up to
 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 465990 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x943ee008
 
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 = 0x839a2718 thread_stack 0x48400
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(my_print_stacktrace+0x2d)[0x887f1bd]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(handle_fatal_signal+0x4ca)[0x83a360a]
 
[0x17d400]
 
/lib/libc.so.6(abort+0x17a)[0x1aa14a]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x871d921]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x86dc9c6]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x86de035]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x86c4052]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x86addaa]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x8643ce6]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x8590f41]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld[0x85923da]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_ZN7handler7ha_openEP5TABLEPKcij+0x32)[0x83abf62]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x7fb)[0x829935b]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z10open_tableP3THDP10TABLE_LISTP18Open_table_context+0x902)[0x8196192]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z11open_tablesP3THDRK14DDL_options_stPP10TABLE_LISTPjjP19Prelocking_strategy+0xc59)[0x8199329]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z29mysqld_show_create_get_fieldsP3THDP10TABLE_LISTP4ListI4ItemEP6String+0xb4)[0x82502e4]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z18mysqld_show_createP3THDP10TABLE_LIST+0x89)[0x82510d9]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z21mysql_execute_commandP3THD+0x2d3d)[0x81df83d]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x2b1)[0x81e84c1]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x29a0)[0x81ebd20]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z10do_commandP3THD+0x2ce)[0x81ec13e]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x194)[0x82c2554]
 
/home/openxs/mariadb-10.1.13-linux-i686/bin/mysqld(handle_one_connection+0x3c)[0x82c277c]
 
/lib/libpthread.so.0(+0x6bc9)[0x62cbc9]
 
/lib/libc.so.6(clone+0x5e)[0x260c9e]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x8ab3f018): show create table test.tinno
 
Connection ID (thread ID): 2
 
Status: NOT_KILLED
 
...

Comment by Valerii Kravchuk [ 2016-04-25 ]

No crash with 32-bit Percona Server 5.6.29-76.2 on the came CentOS 6.7 32-bit VM.

Comment by Jan Lindström (Inactive) [ 2016-04-28 ]

commit ea83c1d7c61f6e267dfbbf01781cbbee7835ebe3
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Thu Apr 28 15:21:10 2016 +0300

MDEV-9977: Crash when accessing large (>4G) InnoDB table on
MariaDB 10.1.x 32-bit binaries.

Problem was the fact that tablespace size was incorrectly
rounded to next extent size (1M).

Comment by Edward_K [ 2017-12-30 ]

Hi,

It looks like this is back again. I'm working with some tables in the 15-20GB range and the test instructions in this bug report reproduce the issue. 32-bit 10.2.x is affected? x64 is fine.
Error log:

2017-12-30 21:47:01 2376 [ERROR] [FATAL] InnoDB: Trying to read page number 1196032 in space 102, space name test/tinno, which is outside the tablespace bounds. Byte offset 0, len 16384
 
171230 21:47:01 [ERROR] mysqld got exception 0x80000003 ;
 
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.2.11-MariaDB
 
key_buffer_size=16777216
 
read_buffer_size=262144
 
max_used_connections=1
 
max_threads=65537
 
thread_count=7
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 24849 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x1f940138
 
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...
 
mysqld.exe!my_parameter_handler()[my_init.c:255]
 
mysqld.exe!raise()[signal.cpp:516]
 
mysqld.exe!abort()[abort.cpp:64]
 
mysqld.exe!ib::fatal::~fatal()[ut0ut.cc:791]
 
mysqld.exe!fil_report_invalid_page_access()[fil0fil.cc:5005]
 
mysqld.exe!fil_io()[fil0fil.cc:5146]
 
mysqld.exe!buf_read_page_low()[buf0rea.cc:192]
 
mysqld.exe!buf_read_page()[buf0rea.cc:462]
 
mysqld.exe!buf_page_get_gen()[buf0buf.cc:4320]
 
mysqld.exe!flst_add_last()[fut0lst.cc:131]
 
mysqld.exe!fsp_free_extent()[fsp0fsp.cc:1629]
 
mysqld.exe!fseg_free_extent()[fsp0fsp.cc:3296]
 
mysqld.exe!fseg_free_step_func()[fsp0fsp.cc:3369]
 
mysqld.exe!btr_free_but_not_root()[btr0btr.cc:1387]
 
mysqld.exe!btr_free_if_exists()[btr0btr.cc:1438]
 
mysqld.exe!dict_drop_index_tree()[dict0crea.cc:1048]
 
mysqld.exe!row_upd_clust_step()[row0upd.cc:3103]
 
mysqld.exe!row_upd()[row0upd.cc:3261]
 
mysqld.exe!row_upd_step()[row0upd.cc:3407]
 
mysqld.exe!que_thr_step()[que0que.cc:1035]
 
mysqld.exe!que_run_threads_low()[que0que.cc:1115]
 
mysqld.exe!que_run_threads()[que0que.cc:1157]
 
mysqld.exe!que_eval_sql()[que0que.cc:1232]
 
mysqld.exe!row_drop_table_for_mysql()[row0mysql.cc:3998]
 
mysqld.exe!ha_innobase::delete_table()[ha_innodb.cc:13670]
 
mysqld.exe!handler::ha_delete_table()[handler.cc:4335]
 
mysqld.exe!ha_delete_table()[handler.cc:2350]
 
mysqld.exe!mysql_rm_table_no_locks()[sql_table.cc:2466]
 
mysqld.exe!mysql_rm_table()[sql_table.cc:2086]
 
mysqld.exe!mysql_execute_command()[sql_parse.cc:4739]
 
mysqld.exe!mysql_parse()[sql_parse.cc:7887]
 
mysqld.exe!dispatch_command()[sql_parse.cc:1804]
 
mysqld.exe!do_command()[sql_parse.cc:1359]
 
mysqld.exe!threadpool_process_request()[threadpool_common.cc:366]
 
mysqld.exe!tp_callback()[threadpool_common.cc:192]
 
mysqld.exe!work_callback()[threadpool_win.cc:451]
 
ntdll.dll!LdrRegisterDllNotification()
 
ntdll.dll!TpCallbackIndependent()
 
kernel32.dll!BaseThreadInitThunk()
 
ntdll.dll!RtlInitializeExceptionChain()
 
ntdll.dll!RtlInitializeExceptionChain()
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x1fa1d548): drop table tinno
 
Connection ID (thread ID): 8
 
Status: NOT_KILLED
 
 
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on
 
 
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
 
information that should help you find out what is causing the crash.

Comment by Daniel Black [ 2018-01-01 ]

reopen as per previous comment.

Comment by Sergei Golubchik [ 2018-01-08 ]

I've created a new bug report for it and copied the above comment there. Edward_K if you'd like to follow the progress, please, watch MDEV-14887

Comment by Dallas Clarke [ 2018-07-19 ]

I've got the same problem. I was importing a very large database, I got tired of waiting, so I killed the console application that was doing the import, but this then seemed to have corrupted the database files. Now, every time I go near the database, even with something like "Drop Database <name>", the server just crashes.

If anyone here can tell me how to safely delete the database without starting the server, or use a command line tool to recover the database, I'd be very grateful.

2018-07-19 21:35:53 2180 InnoDB: Assertion failure in thread 8576 in file fil0fil.cc line 5866
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
180719 21:35:53 [ERROR] mysqld got exception 0x80000003 ;
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.1.13-MariaDB
key_buffer_size=16777216
read_buffer_size=4194304
max_used_connections=2
max_threads=1001
thread_count=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 436636 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0xa112310
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...
mysqld.exe!my_parameter_handler()
mysqld.exe!my_mb_ctype_mb()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?functype@Item_func_dyncol_create@@UBE?AW4Functype@Item_func@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!??0Global_read_lock@@QAE@XZ()
mysqld.exe!??0Global_read_lock@@QAE@XZ()
mysqld.exe!??0Global_read_lock@@QAE@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!?get_ctx@MDL_ticket@@QBEPAVMDL_context@@XZ()
mysqld.exe!??0Global_read_lock@@QAE@XZ()
mysqld.exe!?get_trg_event_map@Update_rows_log_event@@UAEEXZ()
mysqld.exe!?ha_delete_table@handler@@QAEHPBD@Z()
mysqld.exe!?ha_delete_table@@YAHPAVTHD@@PAUhandlerton@@PBD22_N@Z()
mysqld.exe!?mysql_rm_table_no_locks@@YAHPAVTHD@@PAUTABLE_LIST@@_N2222@Z()
mysqld.exe!?mysql_opt_change_db@@YA_NPAVTHD@@PBUst_mysql_lex_string@@PAU2@_NPA_N@Z()
mysqld.exe!?mysql_rm_db@@YA_NPAVTHD@@PAD_N@Z()
mysqld.exe!?mysql_execute_command@@YAHPAVTHD@@@Z()
mysqld.exe!?mysql_parse@@YAXPAVTHD@@PADIPAVParser_state@@@Z()
mysqld.exe!?dispatch_command@@YA_NW4enum_server_command@@PAVTHD@@PADI@Z()
mysqld.exe!?do_command@@YA_NPAVTHD@@@Z()
mysqld.exe!?threadpool_process_request@@YAHPAVTHD@@@Z()
mysqld.exe!?tp_end@@YAXXZ()
KERNEL32.DLL!SortGetHandle()
ntdll.dll!RtlAddAce()
ntdll.dll!TpIsTimerSet()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlValidSecurityDescriptor()
ntdll.dll!RtlValidSecurityDescriptor()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x88d0060): DROP DATABASE `popcherry_prod`
Connection ID (thread ID): 21
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Comment by Dallas Clarke [ 2018-07-23 ]

Just as a note, I used innochecksum.exe application to identify the corrupted table. I then copied the <table>.idb and <table>.frm files from an un-corrupted database into the database directory. This then enabled the drop statement to work.

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