[BUG] myloader Segmentation fault

[snowproud]

Describe the bug
when execute /home/mysql/dbbackup-go/bin/myloader -h xxx -P xxxx -u xxxx -p xxxxx -d /data/dbbak/20240510f5d388/20000/doDr_20240510172358/20000/934_1001456_xxxxx_20000_20240508051226_logical --threads=1 --set-names=binary -x '^(?!(mysql\.|sys\.|test\.|db_infobase\.|infodba_schema\.))' >> /home/mysql/dbbackup-go/logs/myloader_5.log 2>&1
I encountered the Segmentation fault (core dumped)

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /home/mysql/dbbackup-go/lib/libmydumper/libzstd.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/23/6f5c52aaec2db68f123ee0751ddf8ba32bdc50.debug
Core was generated by `/home/mysql/dbbackup-go/bin/myloader -h 11.187.76.255 -P 20000 -u J_XXXXXXXXXXX'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f36cf8addd7 in g_slice_alloc () from /lib64/libglib-2.0.so.0
Missing separate debuginfos, use: debuginfo-install bash-4.2.46-34.tl2.3.x86_64 glib2-2.56.1-9.tl2.x86_64 glibc-2.17-323.tl2.x86_64 libgcc-4.8.5-39.tl2.1.x86_64 libstdc++-4.8.5-39.tl2.1.x86_64 pcre-8.32-17.tl2.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0  0x00007f36cf8addd7 in g_slice_alloc () from /lib64/libglib-2.0.so.0
#1  0x00007f36cf8ae2ce in g_slice_alloc0 () from /lib64/libglib-2.0.so.0
#2  0x00007f36cf88ceaa in g_list_insert_sorted_real () from /lib64/libglib-2.0.so.0
#3  0x0000000000412412 in refresh_table_list_without_table_hash_lock (conf=0x7fff6efcf2d0) at /data/git-code/mydumper/src/myloader_common.c:371
#4  refresh_table_list (conf=0x7fff6efcf2d0) at /data/git-code/mydumper/src/myloader_common.c:387
#5  0x00000000004167e9 in process_filename (filename=0x157d300 "��W\001") at /data/git-code/mydumper/src/myloader_intermediate_queue.c:91
#6  0x0000000000416a18 in process_stream_filename (iflnm=0x157d340) at /data/git-code/mydumper/src/myloader_intermediate_queue.c:161
#7  intermediate_thread () at /data/git-code/mydumper/src/myloader_intermediate_queue.c:197
#8  0x00007f36cf8b85c5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#9  0x00007f36d0270ea5 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f36ce9409fd in clone () from /lib64/libc.so.6

To Reproduce
/home/mysql/dbbackup-go/bin/myloader -h xxx -P xxxx -u xxxx -p xxxxx -d /data/dbbak/20240510f5d388/20000/doDr_20240510172358/20000/934_1001456_11.147.24.162_20000_20240508051226_logical --threads=1 --set-names=binary -x '^(?!(mysql\.|sys\.|test\.|db_infobase\.|infodba_schema\.))' >> /home/mysql/dbbackup-go/logs/myloader_5.log 2>&1

When execute the command repeatedly, it sometimes caused Segmentation fault, and sometimes load success.
I'm confused that what causes this bug.

log

** (myloader:15821): WARNING **: 20:48:08.641: Skiping table: `db_infobase`.`query_response_time`

** (myloader:15821): WARNING **: 20:48:08.701: Skiping table: `infodba_schema`.`local_backup_report`

** (myloader:15821): WARNING **: 20:48:08.705: Skiping table: `infodba_schema`.`free_space`

** (myloader:15821): WARNING **: 20:48:08.718: Skiping table: `db_infobase`.`spes_status`

** (myloader:15821): WARNING **: 20:48:08.767: Skiping table: `infodba_schema`.`global_backup`

** (myloader:15821): WARNING **: 20:48:08.784: Skiping table: `db_infobase`.`master_slave_check`

** (myloader:15821): WARNING **: 20:48:08.787: Skiping table: `db_infobase`.`checksum`

** (myloader:15821): WARNING **: 20:48:08.808: Skiping table: `infodba_schema`.`master_slave_heartbeat`

** (myloader:15821): WARNING **: 20:48:08.825: Skiping table: `infodba_schema`.`local_backup_report`

** (myloader:15821): WARNING **: 20:48:08.849: Skiping table: `infodba_schema`.`spes_status`

** (myloader:15821): WARNING **: 20:48:08.887: Skiping table: `infodba_schema`.`checksum_history`

** (myloader:15821): WARNING **: 20:48:08.915: Skiping table: `infodba_schema`.`master_slave_heartbeat`

** (myloader:15821): WARNING **: 20:48:08.929: Skiping table: `infodba_schema`.`query_response_time`

** (myloader:15821): WARNING **: 20:48:08.956: Skiping table: `infodba_schema`.`checksum`

** (myloader:15821): WARNING **: 20:48:08.988: Skiping table: `infodba_schema`.`check_heartbeat`

** (myloader:15821): WARNING **: 20:48:11.934: Skiping table: `db_infobase`.`check_heartbeat`

** (myloader:15821): WARNING **: 20:48:12.342: Skiping table: `infodba_schema`.`check_heartbeat`

** (myloader:15821): WARNING **: 20:48:13.569: Skiping table: `infodba_schema`.`conn_log`

** (myloader:15821): WARNING **: 20:48:13.706: Skiping table: `infodba_schema`.`checksum`

** (myloader:15821): WARNING **: 20:48:13.864: Skiping table: `db_infobase`.`master_slave_check`

** (myloader:15821): WARNING **: 20:48:14.358: Skiping table: `db_infobase`.`checksum`

** (myloader:15821): WARNING **: 20:48:14.953: Skiping table: `db_infobase`.`check_heartbeat`

What mydumper and myloader version has been used?

myloader0.14.3-1, built against MySQL 5.7.35 with SSL support with ZSTD

Environment (please complete the following information):

• OS version: CentOS Linux release 7.2 (Final)

[snowproud]

I could provide another gdb stack

Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /home/mysql/dbbackup-go/lib/libmydumper/libzstd.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/23/6f5c52aaec2db68f123ee0751ddf8ba32bdc50.debug
Core was generated by `/home/mysql/dbbackup-go/bin/myloader -h xxxxx -P 20000 -u J_XXXXXXXXXX'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000040f98b in cmp_restore_job (rj1=<optimized out>, rj2=0x7f8c540d5e00) at /data/git-code/mydumper/src/myloader_process.c:556
556     /data/git-code/mydumper/src/myloader_process.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install bash-4.2.46-34.tl2.3.x86_64 glib2-2.56.1-9.tl2.x86_64 glibc-2.17-323.tl2.x86_64 libgcc-4.8.5-39.tl2.1.x86_64 libstdc++-4.8.5-39.tl2.1.x86_64 pcre-8.32-17.tl2.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0  0x000000000040f98b in cmp_restore_job (rj1=<optimized out>, rj2=0x7f8c540d5e00) at /data/git-code/mydumper/src/myloader_process.c:556
#1  0x00007f8c9a2c8d98 in g_list_insert_sorted_real () from /lib64/libglib-2.0.so.0
#2  0x0000000000411189 in process_data_filename (filename=filename@entry=0x14afd20 "db_xxsy_game_2034.online_items.00000.00011.sql.zst")
    at /data/git-code/mydumper/src/myloader_process.c:588
#3  0x0000000000416968 in process_filename (filename=0x14afd20 "db_xxsy_game_2034.online_items.00000.00011.sql.zst")
    at /data/git-code/mydumper/src/myloader_intermediate_queue.c:130
#4  0x0000000000416a18 in process_stream_filename (iflnm=0x14afd60) at /data/git-code/mydumper/src/myloader_intermediate_queue.c:161
#5  intermediate_thread () at /data/git-code/mydumper/src/myloader_intermediate_queue.c:197
#6  0x00007f8c9a2f45c5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#7  0x00007f8c9acacea5 in start_thread () from /lib64/libpthread.so.0
#8  0x00007f8c9937c9fd in clone () from /lib64/libc.so.6

It seems that the bug is realted to g_list_insert_sorted_real ()

[davidducos]

Hi @snowproud,
You need to use a newer version of MyDumper.

[snowproud]

Hi @snowproud, You need to use a newer version of MyDumper.

Hi, @davidducos , could you tell me which commit fixed th bug.

Myloader import failed because the backupfile produced by mydumper 0.14 is wrong？

I have tried to import backup（produced by mydumper 0.14-3）with myloader 0.16.1 , but still failed.

[davidducos]

Hi @snowproud, I recommend you to take a backup with the latest version and restore it with the same version that you take the backups. We don't support cross version backup restoration, which doesn't mean that it is not going to work.

[snowproud]

Hi @davidducos， I wonder whether the bug is a known and solved issue.
If it is， could you tell me what causes the bug?

Now I have to restore backup（produced by mydumper 0.14.3), therefore I need to fix the bug of myloader 0.14.3.

[davidducos]

Hi @snowproud, Why don't you try with myloader0.14.5-1? usually, releases within the same major version and higher minor version there is high changes to be compatible.
I don't know which bug could be causing the error, but things like this: process_filename (filename=0x157d300 "��W\001") means that there is a memory leak somewhere...