Bug #91205 dd_upgrade tests failing on Debian
Submitted: 11 Jun 2018 7:22 Modified: 16 Feb 2019 17:34
Reporter: Lars Tangvald Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: XA transactions Severity:S3 (Non-critical)
Version:8.0.12 OS:Any
Assigned to: CPU Architecture:Any

[11 Jun 2018 7:22] Lars Tangvald
Description:
dd_upgrade_test and dd_upgrade_partition are failing most of the time on Debian 9 (and Debian unstable)

= dd_upgrade_test =
main.dd_upgrade_test                     w8 [ fail ]  timeout after 900 seconds
        Test ended at 2018-06-09 22:29:25

Test case timeout after 900 seconds

== /dev/shm/mtr-27248/var-debug/8/log/dd_upgrade_test.log == 
  `a` set('','') DEFAULT NULL
) ENGINE=BLACKHOLE DEFAULT CHARSET=latin1
# Stop the server
# Remove copied files
# Restart the server with default options.
# restart
#
# Bug #27512609 5.7->8.0 UPGRADE CRASH WITH DEFAULT-TIME-ZONE SET
#
#
# Zip file contains data directory of a clean 5.7 server.
# made by: ./mtr --mem --mysqld=--default_time_zone="+01:00" main.1st
#
# Copy zip files from suite location to working location.
# Check that the file exists in the working folder.
# Unzip the zip file.
# Set different paths for --datadir
# Check that the file exits after unzip
# Stop DB server which was created by MTR default
# Start the DB server

 == /dev/shm/mtr-27248/var-debug/8/tmp/analyze-timeout-mysqld.1.err ==
mysqltest: Could not open connection 'default' after 500 attempts: 2002 Can't connect to local MySQL server through socket '/dev/shm/mtr-27248/var-debug/tmp/8/mysqld.1.sock' (2)
safe_process[26393]: Child process: 26394, exit: 1

 - the logfile can be found in '/dev/shm/mtr-27248/var-debug/log/main.dd_upgrade_test/dd_upgrade_test.log'
 - found 'core.21587', moving it to '/dev/shm/mtr-27248/var-debug/log/main.dd_upgrade_test'
 - found 'core.21587' (10/5)

Trying 'dbx' to get a backtrace
sh: echo: I/O error

Trying 'gdb' to get a backtrace
Core generated by '/usr/bin/mysqltest'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--------------------------
[New LWP 21587]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/mysqltest --def'.
Program terminated with signal SIGABRT, Aborted.
#0  0xf77a0c89 in __kernel_vsyscall ()
#0  0xf77a0c89 in __kernel_vsyscall ()
#1  0xf7777df1 in __pthread_kill (threadid=4144887552, signo=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:55
#2  0x566004dc in my_write_core(int) ()
#3  0x565e535c in _start ()

Thread 1 (Thread 0xf70df700 (LWP 21587)):
#0  0xf77a0c89 in __kernel_vsyscall ()
#1  0xf7777df1 in __pthread_kill (threadid=4144887552, signo=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:55
#2  0x566004dc in my_write_core(int) ()
#3  0x565e535c in _start ()

 - deleting it, already saved 5

= dd_upgrade_partition =
main.dd_upgrade_partition                w7 [ fail ]
        Test ended at 2018-06-09 22:33:19

CURRENT_TEST: main.dd_upgrade_partition
mysqltest: In included file ./include/wait_until_connected_again.inc at line 46:
included from /usr/lib/mysql-test/t/dd_upgrade_partition.test at line 85:
At line 43: Server failed to restart

The result from queries just before the failure was:
#
# Bug#25153261 : SEG FAULT IN UPGRADING PARTITIONED TABLE
#
# Set different paths for --datadir
# Copy the remote tablespace & DB zip files from suite location to working location.
# Check that the file exists in the working folder.
# Unzip the zip file.
# Stop DB server which was created by MTR default
# Create a bootstrap file in temp location
MYSQL_TMP_DIR/bootstrap.log
# Start the server. Without fix, there is a segmentation fault in this step.
safe_process[27363]: Child process: 27364, exit: 1

How to repeat:
Run mtr test on Debian 9
[16 Feb 2019 17:34] Paul DuBois
Posted by developer:
 
Fixed in 8.0.16. No longer relevant due to this change:

Previously, after installation of a new version of MySQL, the MySQL
server automatically upgraded the data dictionary tables at the next
startup, after which the DBA was expected to invoke mysql_upgrade
manually to upgrade the system tables in the mysql schema, as well as
objects in other schemas such as the sys schema and user schemas.

The server now performs the tasks previously handled by
mysql_upgrade. After installation of a new MySQL version, the server
now automatically performs all necessary upgrade tasks at the next
startup and is not dependent on the DBA invoking mysql_upgrade. A new
--upgrade server option provides control over how the server performs
automatic data dictionary and server upgrade operations.

This change to the upgrade procedure results in some deprecations:

* mysql_upgrade is deprecated because it is no longer necessary.

* The --no-dd-upgrade server option is deprecated because the --upgrade
  option supersedes it.

mysql_upgrade and the --no-dd-upgrade option will be removed in a
future MySQL version.