[MDEV-19182] mysqldump not always handling SHOW CREATE TRIGGER failures correctly Created: 2019-04-05  Updated: 2020-08-25  Resolved: 2019-04-25

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients
Affects Version/s: 10.1, 10.2.14, 10.2, 10.3, 10.4
Fix Version/s: 10.2.24, 10.1.39, 10.3.15, 10.4.5

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None


 Description   

When a "SHOW CREATE TRIGGER" stamement issued by mysqldump fails, mysqldump automatically assumes that this can only happen due to the server version being too old, and so the SHOW CREATE TRIGGER syntax not being available yet, as it was the case for pre-5.5 MySQL.

I'm handling a case right now where the server clearly supports the syntax, so that SHOW CREATE TRIGGER must have failed for some other reason (which is not known yet).

mysqldump simply applies a catch-all method to all query failures here, falling back to trying to extract trigger information from SHOW CREATE TRIGGERS (note the plural form), and in my case crashes at this attempt.

mysqldump should be more clever here, and only fall back to the backward compatibility mode on actual query syntax errors, but should show the actual server error message and terminate on any other error codes.

 Comments   
Comment by Elena Stepanova [ 2019-04-05 ]

An attempt to run dump_trigger_old and subsequent crash on it are reproducible.

  • start the server, all defaults will do
  • run 

    USE test;
    		 
    CREATE TABLE t1 (a INT);
    		 
    CREATE TRIGGER tr AFTER INSERT ON t1 FOR EACH ROW SET @a=1;

  • (re)move <datadir>/test/tr.TRN file
  • run mysqldump <connection options> test

10.1 1f3bcff1

 
#2  0x00007f18066de157 in fprintf () from /lib/x86_64-linux-gnu/libc.so.6
 
#3  0x000055d0cd3f2e79 in dump_trigger_old (sql_file=0x7f1806a28600 <_IO_2_1_stdout_>, show_triggers_rs=0x55d0cdb5e3f0, show_trigger_row=0x7fff10c09198, table_name=0x55d0cdb623d0 "t1") at /data/src/10.1/client/mysqldump.c:3286
 
#4  0x000055d0cd3f3565 in dump_triggers_for_table (table_name=0x55d0cdb623d0 "t1", db_name=0x7fff10c0b5df "test") at /data/src/10.1/client/mysqldump.c:3472
 
#5  0x000055d0cd3f6813 in dump_all_tables_in_db (database=0x7fff10c0b5df "test") at /data/src/10.1/client/mysqldump.c:4634
 
#6  0x000055d0cd3f5fed in dump_databases (db_names=0x55d0cdb3d1b0) at /data/src/10.1/client/mysqldump.c:4440
 
#7  0x000055d0cd3fa59d in main (argc=1, argv=0x55d0cdb3d1b0) at /data/src/10.1/client/mysqldump.c:6133

10.4 ASAN 3a3d5ba2

 
==7931==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f432f79b496 sp 0x7ffe99723838 bp 0x7ffe99723da0 T0)
 
    #0 0x7f432f79b495 in strlen (/lib/x86_64-linux-gnu/libc.so.6+0x80495)
 
    #1 0x7f432f763d77 in vfprintf (/lib/x86_64-linux-gnu/libc.so.6+0x48d77)
 
    #2 0x7f432f76a156 in _IO_fprintf (/lib/x86_64-linux-gnu/libc.so.6+0x4f156)
 
    #3 0x5640ef51f553 in dump_trigger_old /data/src/10.4/client/mysqldump.c:3338
 
    #4 0x5640ef520313 in dump_triggers_for_table /data/src/10.4/client/mysqldump.c:3528
 
    #5 0x5640ef52559c in dump_all_tables_in_db /data/src/10.4/client/mysqldump.c:4709
 
    #6 0x5640ef524886 in dump_databases /data/src/10.4/client/mysqldump.c:4514
 
    #7 0x5640ef52b6de in main /data/src/10.4/client/mysqldump.c:6216
 
    #8 0x7f432f73b2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
 
    #9 0x5640ef5146f9 in _start (/data/bld/10.4-asan/bin/mysqldump+0x896f9)

(non-ASAN builds of 10.3 and 10.4 don't crash on my machine, but they produce garbage in the trigger dump).

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