[BUG] double free or corruption when using innodb-optimize-keys

[BenjaminBauerBM]

Describe the bug
Running against a double free or corruption error when using myloader with innodb-optimize-keys option since 0.12.3-2 & onwards.
Issue not present with 0.12.3-1.

To Reproduce
Command executed:

• mydumper -v 3 -h $DBHOST --database=${dblist} -F 512 --rows 60000 -t $THREADCOUNT --lock-all-tables --set-names="utf8mb4" -o $BACKUPWORKDIR/backup
• myloader -h $DBHOST --directory=$BACKUPWORKDIR/backup -v 3 --set-names="utf8mb4" --innodb-optimize-keys

What mydumper and myloader version has been used?
0.12.3-2

Expected behavior
exit code = 0

Log

** Message: 10:21:06.490: Thread 2 restoring table `preprod`.`mytable` from /data/dumps/./backup/preprod.mytable-schema.sql
** Message: 10:21:06.490: Creating table `preprod`.`mytable` from content in /data/dumps/./backup/preprod.mytable-schema.sql
** Message: 10:21:06.518: Thread 3 restoring `preprod`.`mytable` part 1 of 1 from preprod.mytable.00000.sql. Progress 1 of 546.
** Message: 10:21:06.533: Thread 3 restoring indexes `preprod`.`mytable`
** Message: 10:21:06.570: Thread 3 restoring constraint `preprod`.`mytable` from `l\u000e\x98&\u007f
** Message: 10:21:06.570: Import timings:
** Message: 10:21:06.570: Data      	| Index    	| Total   	| Table
** Message: 10:21:06.570: 0 00:00:00	| 0 00:00:00	| 0 00:00:00	| `preprod`.`mytable`
double free or corruption (!prev)
Aborted

echo $?
134

Environment (please complete the following information):

• OS version: Amazon Linux 2
• MyDumper version: 0.12.3-2

Additional context
Database : Aurora MySQL 2.0.9.2

[davidducos]

Hi @BenjaminBauerBM ,

Is it possible for you to test with master? you will need to compile it, but I think that we might already fix it.

Please, let me know

[BenjaminBauerBM]

Hi @davidducos , thanks for quick answer.
Indeed I compiled from master and it worked flawlessly with --innodb-optimize-keys=AFTER_IMPORT_ALL_TABLES option
Waiting for the next release then.

Thanks

[davidducos]

Awesome! sorry for that bug! I had been playing with Valgrind to reduce memory leaks and I accidentally introduced some bugs as I had no experience fixing those kind of issues and it has been quite hard to debug. However, I learned a lot so, it will be simpler in the future and I will be able to reduce the posible bugs.

[peng19832]

Awesome! sorry for that bug! I had been playing with Valgrind to reduce memory leaks and I accidentally introduced some bugs as I had no experience fixing those kind of issues and it has been quite hard to debug. However, I learned a lot so, it will be simpler in the future and I will be able to reduce the posible bugs.

haha, I also encountered this problem when restoring data in version 0.12.2.
After that, I upgraded to version 0.12.3-3 and got a similar error #715 when restoring data to near the end, however, I'm not sure if it has anything to do with this option.

[peng19832]

Hi, @davidducos, I used version 0.12.3-3 to reproduce this exception. It is indeed triggered by using the --innodb-optimize-keys option. With or without AFTER_IMPORT_ALL_TABLES, coredump will always be triggered.
Without --innodb-optimize-keys option, coredump will not be triggered
exit code: 134