segmentation fault against Percona 5.5.13
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL Data Dumper |
Fix Released
|
Critical
|
Andrew Hutchings |
Bug Description
Running mydumper against Percona 5.5.13 leads to segmentation fault.
Here some information from gdb:
$ gdb /root/mydumper/
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://
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-
For bug reporting instructions, please see:
<http://
Reading symbols from /root/mydumper/
(gdb) run -B sbtest
Starting program: /root/mydumper/
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000
[Thread debugging using libthread_db enabled]
[New Thread 0x40a00940 (LWP 12660)]
[Thread 0x40a00940 (LWP 12660) exited]
Program received signal SIGSEGV, Segmentation fault.
0x0000003d5a07c0fc in strcasecmp () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003d5a07c0fc in strcasecmp () from /lib64/libc.so.6
#1 0x00000000004067f2 in start_dump (conn=0x610f90) at /root/mydumper/
#2 0x0000000000407118 in main (argc=1, argv=0x7fffffff
(gdb) up
#1 0x00000000004067f2 in start_dump (conn=0x610f90) at /root/mydumper/
708 if (!strcasecmp(
(gdb) p *res
$1 = {row_count = 2, fields = 0x621a40, data = 0x611990, data_cursor = 0x61fa50, lengths = 0x611928, handle = 0x0, methods = 0x621a30, row = 0x0, current_row = 0x0,
field_alloc = {free = 0x1fe000000020, used = 0x5, pre_alloc = 0x0, min_malloc = 11, block_size = 0, block_num = 0, first_block_usage = 0, error_handler = 0x1},
field_count = 1581285888, current_field = 61, eof = 0 '\000', unbuffered_
(gdb) p i
$2 = 6
(gdb) p fields[0]
$10 = {name = 0x621f88 "Id", org_name = 0x621f90 "", table = 0x621f78 "", org_table = 0x621f80 "", db = 0x621f70 "", catalog = 0x621f68 "def", def = 0x0,
length = 11, max_length = 5, name_length = 2, org_name_length = 0, table_length = 0, org_table_length = 0, db_length = 0, catalog_length = 3, def_length = 0,
flags = 32897, decimals = 0, charsetnr = 63, type = MYSQL_TYPE_
(gdb) p fields[1]
$11 = {name = 0x621fc0 "", org_name = 0x621fa8 "", table = 0x621fb0 "", org_table = 0x621fa0 "", db = 0x621f98 "def", catalog = 0x0,
def = 0x10 <Address 0x10 out of bounds>, length = 4, max_length = 4, name_length = 0, org_name_length = 0, table_length = 0, org_table_length = 3, db_length = 0,
catalog_length = 1, def_length = 31, flags = 8, decimals = 253, charsetnr = 0, type = 6430696, extension = 0x621ff0}
(gdb) p fields[2]
$12 = {name = 0x621fd8 "", org_name = 0x621fe0 "", table = 0x621fd0 "", org_table = 0x621fc8 "def", db = 0x0, catalog = 0x40 <Address 0x40 out of bounds>,
def = 0x9 <Address 0x9 out of bounds>, length = 4, max_length = 0, name_length = 0, org_name_length = 3, table_length = 0, org_table_length = 1, db_length = 31,
catalog_length = 8, def_length = 253, flags = 0, decimals = 6430744, charsetnr = 0, type = 6430752, extension = 0x622008}
(gdb) p fields[3]
$13 = {name = 0x622010 "", org_name = 0x622000 "", table = 0x621ff8 "def", org_table = 0x0, db = 0x40 <Address 0x40 out of bounds>,
catalog = 0x6 <Address 0x6 out of bounds>, def = 0x2 <Address 0x2 out of bounds>, length = 0, max_length = 12884901888, name_length = 0, org_name_length = 0,
table_length = 31, org_table_length = 8, db_length = 253, catalog_length = 0, def_length = 6430792, flags = 0, decimals = 6430800, charsetnr = 0, type = 6430776,
extension = 0x622040}
(gdb) p fields[4]
$14 = {name = 0x622030 "", org_name = 0x622028 "def", table = 0x0, org_table = 0x10 <Address 0x10 out of bounds>, db = 0x5 <Address 0x5 out of bounds>,
catalog = 0x7 <Address 0x7 out of bounds>, def = 0x0, length = 12884901888, max_length = 4294967296, name_length = 31, org_name_length = 8, table_length = 253,
org_table_length = 0, db_length = 6430840, catalog_length = 0, def_length = 6430848, flags = 0, decimals = 6430824, charsetnr = 0, type = 6430832,
extension = 0x622060}
(gdb) p fields[5]
$15 = {name = 0x622058 "def", org_name = 0x0, table = 0x7 <Address 0x7 out of bounds>, org_table = 0x3 <Address 0x3 out of bounds>,
db = 0x4 <Address 0x4 out of bounds>, catalog = 0x0, def = 0x300000000 <Address 0x300000000 out of bounds>, length = 141291539136512, max_length = 270582939648,
name_length = 3, org_name_length = 0, table_length = 6430888, org_table_length = 0, db_length = 6430896, catalog_length = 0, def_length = 6430872, flags = 0,
decimals = 6430880, charsetnr = 0, type = 6430864, extension = 0x622088}
(gdb) p fields[6]
$16 = {name = 0x0, org_name = 0x1e <Address 0x1e out of bounds>, table = 0x0, org_table = 0x5 <Address 0x5 out of bounds>, db = 0x0,
catalog = 0x300000000 <Address 0x300000000 out of bounds>, def = 0x0, length = 34359738399, max_length = 253, name_length = 6430936, org_name_length = 0,
table_length = 6430944, org_table_length = 0, db_length = 6430920, catalog_length = 0, def_length = 6430928, flags = 0, decimals = 6430912, charsetnr = 0,
type = 6430904, extension = 0x0}
field_count = 1581285888 sounds pretty odd.
After some digging, it looks that the problem is in the use of libmysqlclient_r :
mydumper uses libmysqlclient_
Changed in mydumper: | |
importance: | High → Critical |
Hi Rene,
Thanks for the bug report. Very interesting, I have not tried against Percona yet. It does look like that struct array hasn't been populated correctly/ completely.
Can you please provide the output of mysql_config for that system and 'ldd mydumper'? It should help me determine where in the linker that is happening.
Also, what version of mydumper is used? (not that I think I have changed anything that could be related from 0.2 to 0.5)