MySQL Bugs: #28560: mysql_upgrade test links /usr/local/mysql/lib libraries

Bug #28560	mysql_upgrade test links /usr/local/mysql/lib libraries
Submitted:	21 May 2007 13:18	Modified:	4 Sep 2007 18:17
Reporter:	Stewart Smith	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Tests	Severity:	S7 (Test Cases)
Version:	5.1.18, telco	OS:	Any
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
the mysql_upgrade test will run a binary dynamically linked against the *wrong* libraries. If you have /usr/local/mysql/lib/mysql/libmysqlclient.so.15 and 5.1 test, it will link against the /usr/local/mysql lib instead of the one in the tree.

/usr/local/mysql/lib is *NOT* in /etc/ld.so.conf (or any env variable

*** glibc detected *** /home/stewart/Documents/MySQL/5.1/ndb-work/client/.libs/mysql: munmap_chunk(): invalid pointer: 0x080770b0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__libc_free+0x18a)[0xb7b3fb4a]
/usr/local/mysql/lib/mysql/libmysqlclient.so.15(my_no_flags_free+0x86)[0xb7db7d66]
/home/stewart/Documents/MySQL/5.1/ndb-work/client/.libs/mysql[0x80537d6]
/home/stewart/Documents/MySQL/5.1/ndb-work/client/.libs/mysql(main+0x939)[0x8057435]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7aee8cc]
/home/stewart/Documents/MySQL/5.1/ndb-work/client/.libs/mysql[0x804f7a1]

How to repeat:
have old mysql 5.1 in /usr/local/mysql, run 5.1 test

Suggested fix:
don't link to mysql libraries installed on system.

This is most likely an effect of running binaries from libtool wrappers(although the bug is not in libtool itsefl).

When mysql_upgrade start it wil look for mysql and mysqlcheck in the same directories from where it was started. In the case when it's run from a libtool wrapper it will find the binaries in .libs/ Those binaries are the "raw binaries" i.e compiled with /usr/local/mysql unless no special prefix was used. Nommally libtool would relink them to get binaries from ../libmysqlclient/.libs/ first.

That does not happen now. There is code in mysql_upgrade to looking in the higher level directory if the binaries is not runnable - which they aren't  unles you have a version  of mysql installed - but that obviously works in this case.

Probably need to look at the name of the mysql_upgrade binary - if it's lt-mysql_upgrade -> look directly in  higher level dir.

...or if there is a another way to figure out that mysql_upgrade is being rrun from it's libtool wrapper.

Only affects build from source repo.

hrrrm... this could be something else....

I've managed to get something similar (this time missing symbols) with ~mysql/ built with debug and /usr/local/mysql built without debug.

mysql@saturn:~/mysql-5.1.18-ndb-6.2.3$ ./client/mysql_upgrade -u root -S /tmp/mysql.sock -p
Enter password: 
Looking for 'mysql' in: /home/mysql/mysql-5.1.18-ndb-6.2.3/client/.libs/mysql
Looking for 'mysqlcheck' in: /home/mysql/mysql-5.1.18-ndb-6.2.3/client/.libs/mysqlcheck
Running 'mysqlcheck'...
/home/mysql/mysql-5.1.18-ndb-6.2.3/client/.libs/mysqlcheck: relocation error: /home/mysql/mysql-5.1.18-ndb-6.2.3/client/.libs/mysqlcheck: symbol _db_enter_, version libmysqlclient_15 not defined in file libmysqlclient.so.15 with link time reference
FATAL ERROR: Upgrade failed

(this was running with the attached patch)

Yes, running  plain "mysql_upgrade" from a noninstalled tree will still find the non relinked "mysqlcheck" - which will try to link with /usr/local/mysql/lib...
If you pass it --bindir=<dir of mysqlcheck and mysql> it will work. 

Maybe we need to fix this too? If there just was a way to detect if mysql_upgrade was executed from it's libtool wrapper. I have really looked in those wrapper scripts to see if it set an environment variable or something but no luck. Maybe we can cram one in there ourself? 

Other alternatives are:
1. If path is <path>/.libs/ -> look in directory one level up for mysqlcheck. But does really libtool always put the binaries in .libs/ and is it one level up?
2. If binary name is lt-mysql_upgrade -> same as above.
3. Change libtool to use a different name of the non relinked binaries. If they would have been called lt-mysqlcheck instead and the relinked binary would have been called mysqlcheck this would have worked. ;)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/28664

ChangeSet@1.2537, 2007-06-13 23:33:37+10:00, stewart@flamingspork.com +1 -0
  [PATCH] Disable mysql_upgrade test (Bug#28560)
  
  Index: ndb-work/mysql-test/t/disabled.def
  ===================================================================

have pushed adding mysql_upgrade test to disabled.def into 5.1-ndb because of this bug.

Pushed into 5.1.20-beta

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/33130

ChangeSet@1.2501, 2007-08-27 10:25:34+02:00, msvensson@pilot.(none) +1 -0
  Bug#28560 mysql_upgrade test links /usr/local/mysql/lib libraries
   - Chop off .libs/ part of path if running in non installed builddir
     using libtool

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/33132

ChangeSet@1.2570, 2007-08-27 11:20:31+02:00, msvensson@pilot.(none) +1 -0
  Bug#28560 mysql_upgrade test links /usr/local/mysql/lib libraries
   - Remove disabling of mysql_upgrade

Pushed into 5.1.23-beta

Pushed into 5.0.50

Noted in 5.0.50, 5.1.23 changelogs.

mysql_upgrade could run binaries dynamically linked against incorrect
versions of shared libraries.