[MDEV-18782] mysqldump --all-databases causes segmentation fault Created: 2019-03-01  Updated: 2019-05-24  Resolved: 2019-05-07

Status: Closed
Project: MariaDB Server
Component/s: Backup, Scripts & Clients
Affects Version/s: 10.3.13
Fix Version/s: 10.3.15

Type: Bug Priority: Major
Reporter: Avi Deitcher Assignee: Alexey Botchkov
Resolution: Fixed Votes: 0
Labels: None
Environment:

alpine 3.9 on docker


 Description   

I am running a mysql 8.0.15 docker container. I have a separate container running Alpine Linux 3.9, in which I install both mariadb-client and mariadb-connector-c.

In the server I set up an empty databases `tester`. I then run:

  • `mysqldump -h mysql -uuser -pabcdefg --databases tester` - this works
  • `mysqldump -h mysql -uuser -pabcdefg --all-databases` - this crashes with a segmentation fault

/ # mysqldump -h mysql -uuser -pabcdefg --verbose --all-databases
 
-- Connecting to mysql...
 
-- MySQL dump 10.17  Distrib 10.3.13-MariaDB, for Linux (x86_64)
 
--
 
-- Host: mysql    Database:
 
-- ------------------------------------------------------
 
-- Server version	8.0.14
 
 
 
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
 
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
 
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
 
/*!40101 SET NAMES utf8mb4 */;
 
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
 
/*!40103 SET TIME_ZONE='+00:00' */;
 
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
 
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
 
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
 
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
 
Segmentation fault

Unsure if the `mariadb-connector-c` install is affecting it somehow (although I need it for the caching_sha2_password plugin); it is an issue with the Alpine package, or something else.

FYI, the Alpine package source is here https://git.alpinelinux.org/aports/tree/main/mariadb?h=master

 Comments   
Comment by Avi Deitcher [ 2019-03-03 ]

Managed to build `mysqldump` with debug symbols and ran it. Some more useful info:

(gdb) bt full
 
#0  0x00007ffab3728a28 in strcmp () from /lib/ld-musl-x86_64.so.1
 
No symbol table info available.
 
#1  0x00005571e86b7283 in dump_tablespaces (ts_where=0x0)
 
    at /home/abuild/aports/main/mariadb/src/mariadb-10.3.13/client/mysqldump.c:4342
 
        row = 0x5571e93750f0
 
        tableres = 0x5571e9374fe0
 
        buf = '\000' <repeats 16 times>, "\300\202v\263\372\177\000\000\372\326o\263\372\177\000\000\350\230v\263\372\177\000\000\200$\000\000\000\000\000\000,", '\000' <repeats 15 times>, "\240I\246\350qU\000\000\020\a7\351qU\000\000#\000\000\000\000\000\000\000-", '\000' <repeats 11 times>, "\376\377\377\377`\216v\263\372\177\000\000 \212v\263\372\177\000\000I\335o\263\372\177\000\000V\274k\350qU\000\000`\004", '\000' <repeats 14 times>, "\004\036p\350qU\000\000\300s.\213\375\177\000\000\004\036p\350qU\000\000\320s.\213\375\177\000\000\000N5\351qU\000\000\340s.\213\375\177\000\000"...
 
        sqlbuf = {
 
          str = 0x5571e9370bb0 "SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL GROUP BY LOGFILE_GROUP_NAME, FILE_"...,
 
          length = 240, max_length = 1024, alloc_increment = 1024}
 
        first = 0
 
        extra_format = "UNDO_BUFFER_SIZE="
 
        ubs = 0x7ffab37682c0 "\005"
 
        endsemi = 0x7ffd8b2e7360 ""
 
        _db_stack_frame_ = {func = 0x5571e8753de5 "?func", file = 0x5571e8753deb "?file", level = 2147483649, line = -1,
 
          prev = 0x0}
 
#2  0x00005571e86b6c87 in dump_all_tablespaces ()
 
    at /home/abuild/aports/main/mariadb/src/mariadb-10.3.13/client/mysqldump.c:4203
 
No locals.
 
#3  0x00005571e86bc090 in main (argc=0, argv=0x5571e93562e0)
 
    at /home/abuild/aports/main/mariadb/src/mariadb-10.3.13/client/mysqldump.c:6197
 
        bin_log_name = "\300u.\213\375\177\000\000\274u.\213\375\177\000\000\270u.\213\375\177\000\000\264u.\213\375\177\000\000\300u.\213\000\000\000\000\000vm\263\372\177\000\000\000\000\000\000\000\000\000\000˛e\263\372\177\000\000\000\a5\351\026\0--Type <RET> for more, q to quit, c to continue without paging--
 
00\000\000GenuntelineI\000\000\000\000\347\377\377\377\000\000\000\000\001\000\000\000\000\000\000\000\305=S\023\314\003\231\177\000\000\000\000\000\000\000\000gro\263\372\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\370vm\263\372\177\000\000\305=S\023\314\003\231\177\000\000\000\000\000\000\000\000Tu[\263\372\177\000\000P\000\000\000\000\000\000\000\240\211m\263\372\177\000\000\000\000\000\000\000\000\000\000\240"...
 
        exit_code = 0
 
        consistent_binlog_pos = 0
 
        have_mariadb_gtid = 0

The `strcmp()` that causes the fault is at mysqldump.c:4342 :

  buf[0]= 0;
 
  while ((row= mysql_fetch_row(tableres)))
 
  {
 
    if (strcmp(buf, row[0]) != 0)
 
      first= 1;

When run through a debugger:

(gdb) b mysqldump.c:4342
 
Breakpoint 1 at 0x3a267: file /home/abuild/aports/main/mariadb/src/mariadb-10.3.13/client/mysqldump.c, line 4342.
 
(gdb) run -h mysql -uuser -pabcdefg --verbose --all-databases
 
...
 
Breakpoint 1, dump_tablespaces (ts_where=0x0) at /home/abuild/aports/main/mariadb/src/mariadb-10.3.13/client/mysqldump.c:4342
 
4342	    if (strcmp(buf, row[0]) != 0)
 
(gdb) p buf
 
$1 = '\000' <repeats 16 times>, "\300\262\377\367\377\177\000\000\372\006\371\367\377\177\000\000\350\310\377\367\377\177\000\000\200$\000\000\000\000\000\000,", '\000' <repeats 15 times>, "\240\271\223UUU\000\000\020ǗUUU\000\000#\000\000\000\000\000\000\000-", '\000' <repeats 11 times>, "\376\377\377\377`\276\377\367\377\177\000\000 \272\377\367\377\177\000\000I\r\371\367\377\177\000\000V,YUUU\000\000`\004", '\000' <repeats 14 times>, "\004\216]UUU\000\000`\350\377\377\377\177\000\000\004\216]UUU\000\000p\350\377\377\377\177\000\000\000\016\226UUU\000\000\200\350\377\377\377\177\000\000\027"...
 
(gdb) p row
 
$2 = (MYSQL_ROW) 0x5555559810f0
 
(gdb) p row[0]
 
$3 = 0x0

That might do it. The question is, why is it getting a null for `row[0]`?

Comment by Elena Stepanova [ 2019-03-11 ]

holyfoot, could you please look into it?

Comment by Avi Deitcher [ 2019-05-05 ]

Any updates or insights?

Comment by Alexey Botchkov [ 2019-05-07 ]

http://lists.askmonty.org/pipermail/commits/2019-May/013754.html

Comment by Avi Deitcher [ 2019-05-07 ]

Thanks Alexey. So it is merged into 10.3.15? Will give it a shot.

Comment by Avi Deitcher [ 2019-05-07 ]

I love when I hit "Add" by accident before I am done. Sigh. Correction:

Thanks Alexey. So it is merged into 10.3.15? Will give it a shot. When is 10.3.15 expected available?

Comment by Alexey Botchkov [ 2019-05-08 ]

Hi, Avi!
Yes, this is merged into 10.3.15. Will be available next week i belive.

Comment by Avi Deitcher [ 2019-05-08 ]

Thanks Alexey!

Comment by Avi Deitcher [ 2019-05-24 ]

And ran a full test in my scenarios, looks great. Thanks again, have a great weekend.

Generated at Thu Feb 08 08:46:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.