Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
7 of 7

LP #1540296: Getting error while taking percona incremental backup

Cannot Reproduce

Description

**Reported in Launchpad by santhosh last update 10-04-2016 04:17:23

Getting the below error
2016-02-01 10:21:53 7fde8e398700 InnoDB: Assertion failure in thread 140593845602048 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.
10:21:54 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.

Environment

None

Smart Checklist

Details

Assignee

Reporter

Labels

Priority

Smart Checklist

Created January 19, 2018 at 11:42 PM
Updated February 5, 2018 at 11:29 AM
Resolved January 19, 2018 at 11:42 PM
Configure

Activity

Show:

lpjirasync January 19, 2018 at 11:44 PM

**Comment from Launchpad by: Launchpad Janitor on: 10-04-2016 04:17:21

[Expired for Percona XtraBackup because there has been no activity for 60 days.]

lpjirasync January 19, 2018 at 11:43 PM

**Comment from Launchpad by: santhosh on: 08-02-2016 12:04:01

This issue is due to malloc only when I tried with 4G of RAM there was no issue,
Thanks percona support team.
Pls close this incident

lpjirasync January 19, 2018 at 11:43 PM

**Comment from Launchpad by: santhosh on: 08-02-2016 09:37:14

I tried gdb:

gdb --args innobackupex --incremental /AZVOL/phy_backup/inc --user=backup_user --password=XXXXXXXX --incremental-basedir=/AZVOL/phy_backup/2016-02-08_07-52-26/
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/xtrabackup...Reading symbols from /usr/bin/xtrabackup...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install percona-xtrabackup-2.3.3-1.el7.x86_64
(gdb)
(gdb)
(gdb) bt
No stack.
(gdb) t apply bt full
(gdb)
(gdb) quit

lpjirasync January 19, 2018 at 11:43 PM

**Comment from Launchpad by: santhosh on: 08-02-2016 09:04:31

I am able to take core dump , my script for taking full backup works fine , only in incremental backup i am facing this.
Let me try with 4G RAM and check if its related to malloc.

lpjirasync January 19, 2018 at 11:43 PM

**Comment from Launchpad by: santhosh on: 08-02-2016 08:54:17

I am able to take core dump , my script for taking full backup works fine , only in incremental backup i am facing this.
Let me try with 4G RAM and check if its related to malloc.

I cant get your comment :

also I don't see how it affects security

information type: Private Security → Public

please brief me on that.

thanks

Loading...