| Bug #72285 | Failing assertion: ret || !assert_on_error | ||
|---|---|---|---|
| Submitted: | 9 Apr 2014 8:45 | Modified: | 3 Apr 2018 22:40 |
| Reporter: | Ahmed Abbas | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: Connection Handling | Severity: | S2 (Serious) |
| Version: | 5.5.31 | OS: | Linux (Ubuntu 12.04) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | assertion failure | ||
[9 Apr 2014 8:45]
Ahmed Abbas
[9 Apr 2014 10:41]
MySQL Verification Team
Looks like server ran out of memory. Had you checked that my.cnf options aren't too large and that enough free memory available when you run that query?
[10 May 2014 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[26 Oct 2015 7:40]
Shahriyar Rzayev
The most easy way to reproduce this is running innobackupex with --parallel=1000000000000 Description: [root@node1 mysql]# mysqld --version mysqld Ver 5.6.26-74.0 for Linux on x86_64 (Percona Server (GPL), Release 74.0, Revision 32f8dfd) [root@node1 mysql]# xtrabackup --version xtrabackup version 2.3.2 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 306a2e0) [root@node1 mysql]# innobackupex --defaults-file=/etc/my.cnf --user=root --password=12345 --port=3306 --socket=/var/lib/mysql/mysql.sock --parallel=1000000000000 /home/MySQL-AutoXtraBackup/backup_dir/full/ Warning: option 'parallel': signed value 1000000000000 adjusted to 2147483647 151026 11:13:36 innobackupex: Starting the backup operation xtrabackup: Generating a list of tablespaces xtrabackup: Starting 2147483647 threads for parallel data files transfer 2015-10-26 11:13:37 7f938241e740 InnoDB: Assertion failure in thread 140271522277184 in file ut0mem.cc line 105 InnoDB: Failing assertion: ret || !assert_on_error 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. 07:13:37 UTC - xtrabackup got signal 6 ; This could be because you hit a bug or data is corrupted. This error can also be caused by malfunctioning hardware. 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. Thread pointer: 0x0 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 = 0 thread_stack 0x10000 innobackupex(my_print_stacktrace+0x2e) [0x927d2e] innobackupex(handle_fatal_signal+0x262) [0x7214b2] /lib64/libpthread.so.0(+0xf130) [0x7f9381ffe130] /lib64/libc.so.6(gsignal+0x37) [0x7f938076b5d7] /lib64/libc.so.6(abort+0x148) [0x7f938076ccc8] innobackupex(ut_malloc_low(unsigned long, unsigned long)+0x13c) [0x6d285c] innobackupex(xtrabackup_backup_func()+0xa8d) [0x599ccd] innobackupex(main+0xa95) [0x57de65] /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f9380757af5] innobackupex() [0x591bc9]
[3 Mar 2018 22:40]
MySQL Verification Team
Please check the comments done by Shane, try latest released version too. Thanks.
[4 Apr 2018 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
