LP #403313: innobackupex-1.5.1 core dump (xtrabackup)

**Comment from Launchpad by: Thiago Damas on: 17-12-2009 11:37:08

Yes, its working now!!
Thanks a lot!!

[]s

On Thu, Dec 17, 2009 at 6:34 AM, Yasufumi Kinoshita <
yasufumi.kinoshita@percona.com> wrote:

> ** Changed in: percona-xtrabackup
> Status: New => Fix Released
>
> –
> innobackupex-1.5.1 core dump (xtrabackup)
> https://bugs.launchpad.net/bugs/403313
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Open source backup tool for InnoDB and XtraDB: Fix Released
>
> Bug description:
> I'm using xtrabackup 0.8rc1 (from binary package) on freebsd 7.2, mysql
> 5.0.81
> FreeBSD db03.vetorial.net 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue
> Jun 9 18:02:21 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> Running innobackupex OK, but when execute with --apply-log, it generates a
> core dump in xtrabackup:
> db03# gdb /usr/local/bin/xtrabackup xtrabackup.core
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> Core was generated by `xtrabackup'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libthr.so.3...done.
> Loaded symbols for /lib/libthr.so.3
> Reading symbols from /lib/libc.so.7...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0 0x00000000004e7010 in os_mutex_enter (mutex=0x2027d4440) at
> os0sync.c:582
> 582 os0sync.c: No such file or directory.
> in os0sync.c
> [New Thread 0x200b020b0 (LWP 100149)]
> (gdb) bt
> #0 0x00000000004e7010 in os_mutex_enter (mutex=0x2023dc440) at
> os0sync.c:582
> #1 0x00000000004e8ccf in os_file_pread (file=3, buf=0x200b30800, n=2048,
> offset=0, offset_high=0) at os0file.c:1946
> #2 0x00000000004e8ee8 in os_file_read (file=3, buf=0x200b30800, offset=0,
> offset_high=0, n=2048) at os0file.c:2184
> #3 0x0000000000403307 in xtrabackup_close_temp_log (clear_flag=Variable
> "clear_flag" is not available.
> ) at xtrabackup.c:3239
> #4 0x00000000004066a6 in xtrabackup_prepare_func () at xtrabackup.c:3545
> #5 0x0000000000408493 in main (argc=0, argv=0x200b1a848) at
> xtrabackup.c:3793
>
>
> it's 100% reproducible (same results on another machine)
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/403313/+subscribe
>

**Comment from Launchpad by: Thiago Damas on: 14-09-2009 13:51:26

Hi,
I'll try now!!
Thanks

Thiago

On Mon, Sep 14, 2009 at 6:02 AM, Yasufumi Kinoshita
<yasufumi.kinoshita@percona.com> wrote:
> This bug might be already fixed at
> http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/89
>
> –
> innobackupex-1.5.1 core dump (xtrabackup)
> https://bugs.launchpad.net/bugs/403313
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Open source backup tool for InnoDB and XtraDB: New
>
> Bug description:
> I'm using xtrabackup 0.8rc1 (from binary package) on freebsd 7.2, mysql 5.0.81
> FreeBSD db03.vetorial.net 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun  9 18:02:21 UTC 2009     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>
> Running innobackupex OK, but when execute with --apply-log, it generates a core dump in xtrabackup:
> db03# gdb /usr/local/bin/xtrabackup xtrabackup.core
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> Core was generated by `xtrabackup'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libthr.so.3...done.
> Loaded symbols for /lib/libthr.so.3
> Reading symbols from /lib/libc.so.7...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x00000000004e7010 in os_mutex_enter (mutex=0x2027d4440) at os0sync.c:582
> 582     os0sync.c: No such file or directory.
>        in os0sync.c
> [New Thread 0x200b020b0 (LWP 100149)]
> (gdb) bt
> #0  0x00000000004e7010 in os_mutex_enter (mutex=0x2023dc440) at os0sync.c:582
> #1  0x00000000004e8ccf in os_file_pread (file=3, buf=0x200b30800, n=2048, offset=0, offset_high=0) at os0file.c:1946
> #2  0x00000000004e8ee8 in os_file_read (file=3, buf=0x200b30800, offset=0, offset_high=0, n=2048) at os0file.c:2184
> #3  0x0000000000403307 in xtrabackup_close_temp_log (clear_flag=Variable "clear_flag" is not available.
> ) at xtrabackup.c:3239
> #4  0x00000000004066a6 in xtrabackup_prepare_func () at xtrabackup.c:3545
> #5  0x0000000000408493 in main (argc=0, argv=0x200b1a848) at xtrabackup.c:3793
>
>
>  it's 100% reproducible (same results on another machine)
>

**Comment from Launchpad by: Yasufumi Kinoshita on: 14-09-2009 09:02:07

This bug might be already fixed at
http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/89

**Comment from Launchpad by: Thiago Damas on: 21-08-2009 13:13:22

Hi,
my machine has 4G RAM
at first, I tried
innobackupex-1.5.1 --defaults-file=/var/db/mysql/my.cnf --apply-log
2009-07-23_03-08-16/
but got a core dump

After, I checked that innobackupex was using too much memory, and I
have on my my.cnf
innodb_buffer_pool_size = 2G

So, running
innobackupex-1.5.1 --defaults-file=/var/db/mysql/my.cnf --apply-log
2009-07-23_03-08-16/
giving a core dump, but without deleting my files, I tried again
innobackupex-1.5.1 --defaults-file=/var/db/mysql/my.cnf
--use-mem=1048576 --apply-log 2009-07-23_03-08-16/

and it worked with no errors

The other bug was with -help option
innobackupex --help has a problem:
--use-memory=MB
the correct i think its:
--use-memory=B

Thiago

On Fri, Aug 21, 2009 at 4:20 AM, Yasufumi
Kinoshita<yasufumi.kinoshita@percona.com> wrote:
> Sorry, I don't understand clearly what you reported.
>
> The crush of your first post is caused by shortage of memory and mutex
> has not been allocated?
>
> And, you use innodb_buffer_pool_size = 2G.
> But xtrabackup don't use innodb_buffer_pool_size.
> Does your second post means 2G used by mysqld is almost of your memory of the server??
>
> I don't know what option did you use for innobackupex/xtrabackup.
> And I also don't know how much memory your server has....
>
> In the end, is the problem --help message of innobackupex only?
>
> ** Changed in: percona-xtrabackup
>   Importance: High => Low
>
> –
> innobackupex-1.5.1 core dump (xtrabackup)
> https://bugs.launchpad.net/bugs/403313
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Open source backup tool for InnoDB and XtraDB: New
>
> Bug description:
> I'm using xtrabackup 0.8rc1 (from binary package) on freebsd 7.2, mysql 5.0.81
> FreeBSD db03.vetorial.net 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun  9 18:02:21 UTC 2009     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>
> Running innobackupex OK, but when execute with --apply-log, it generates a core dump in xtrabackup:
> db03# gdb /usr/local/bin/xtrabackup xtrabackup.core
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> Core was generated by `xtrabackup'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libthr.so.3...done.
> Loaded symbols for /lib/libthr.so.3
> Reading symbols from /lib/libc.so.7...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x00000000004e7010 in os_mutex_enter (mutex=0x2027d4440) at os0sync.c:582
> 582     os0sync.c: No such file or directory.
>        in os0sync.c
> [New Thread 0x200b020b0 (LWP 100149)]
> (gdb) bt
> #0  0x00000000004e7010 in os_mutex_enter (mutex=0x2023dc440) at os0sync.c:582
> #1  0x00000000004e8ccf in os_file_pread (file=3, buf=0x200b30800, n=2048, offset=0, offset_high=0) at os0file.c:1946
> #2  0x00000000004e8ee8 in os_file_read (file=3, buf=0x200b30800, offset=0, offset_high=0, n=2048) at os0file.c:2184
> #3  0x0000000000403307 in xtrabackup_close_temp_log (clear_flag=Variable "clear_flag" is not available.
> ) at xtrabackup.c:3239
> #4  0x00000000004066a6 in xtrabackup_prepare_func () at xtrabackup.c:3545
> #5  0x0000000000408493 in main (argc=0, argv=0x200b1a848) at xtrabackup.c:3793
>
>
>  it's 100% reproducible (same results on another machine)
>

**Comment from Launchpad by: Yasufumi Kinoshita on: 21-08-2009 07:20:43

Sorry, I don't understand clearly what you reported.

The crush of your first post is caused by shortage of memory and mutex has not been allocated?

And, you use innodb_buffer_pool_size = 2G.
But xtrabackup don't use innodb_buffer_pool_size.
Does your second post means 2G used by mysqld is almost of your memory of the server??

I don't know what option did you use for innobackupex/xtrabackup.
And I also don't know how much memory your server has....

In the end, is the problem --help message of innobackupex only?