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 15:18	Modified:	4 Sep 2007 20:17
Reporter:	Stewart Smith
Status:	Closed
Category:	Server: Tests	Severity:	S2 (Serious)
Version:	5.1.18, telco	OS:	Any
Assigned to:	Magnus Svensson	Target Version:

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.