MySQL Bugs: #42144: plugin_load fails on PPC64

Bug #42144	plugin_load fails on PPC64
Submitted:	16 Jan 1:46	Modified:	22 Jan 22:15
Reporter:	[ name withheld ]
Status:	Verified
Category:	Server	Severity:	S3 (Non-critical)
Version:	5.1.30, azalea	OS:	Linux (Fedora (both F10 and rawhide) PPC64, AIX 5.3 PPC64, Solaris Sparc)
Assigned to:		Target Version:	5.1+
Triage:	Triaged: D3 (Medium)

Description:
The plugin_load regression test expects the variable global.example_enum_var to still
have the value that was assigned to it midway through the previous regression test
(plugin).  However, since plugin.test ends with 
UNINSTALL PLUGIN example;
it seems to me that the correct response would be
Unknown system variable 'example_enum_var'
... at least that's what I get when I do the same sequence of operations manually.

I think that the results shown in plugin.result are an artifact of a race condition (ie,
the plugin isn't unloaded quite yet).  The reason my attention got drawn to this is that
the plugin_load regression test
is showing a platform-dependent failure in my testing on Fedora (F10 and rawhide) --- on
PPC64 it
seems to usually yield 0 (ie equality failure) rather than 1 (equality).  The best
hypothesis I can think of is that the timing is a bit different on that hardware and we
are seeing the value of the variable after it's been reset to zero, but still before the
plugin is completely unloaded.  Manual execution of the test
produces the results I expect on both this platform and others.

If you think the regression tests are actually showing sane results, please explain why
manual execution produces a different result.

How to repeat:
Here's the manual behavior:

mysql> INSTALL PLUGIN example SONAME 'ha_example.so';
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL example_enum_var= e2;
Query OK, 0 rows affected (0.00 sec)

mysql> UNINSTALL PLUGIN example;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT @@global.example_enum_var = 'e2';
ERROR 1193 (HY000): Unknown system variable 'example_enum_var'

Why doesn't this match the regression test results?

Suggested fix:
For the moment I'm just diking the plugin_load test out of the Fedora package.  If it is
a race condition and you don't intend to get rid of it, maybe inserting a small delay
into this test would be appropriate.

Thank you for taking the time to write to us, but this is not a bug. Please double-check
the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Test plugin_load contains option file plugin_load-master.opt which forces
mysql-test-run.pl re-locad EXAMPLE plugin and additional check if plugin EXAMPLE is
installed.

okay ... so why does it fail on ppc64?

Thank you for the feedback.

Test should not fail. Please provide error message you get and log files: content of
MYSQL_PATH/mysql-test/var/log directory. Also please confirm you run Fedora on ppc64.

There's no error message, it just delivers an unexpected result:

--- /home/tgl/rpmwork/BUILD/mysql-5.1.30/mysql-test/r/plugin_load.result	2008-11-14
20:30:54.000000000 +0300
+++ /home/tgl/rpmwork/BUILD/mysql-5.1.30/mysql-test/r/plugin_load.reject	2009-01-16
02:34:06.000000000 +0300
@@ -1,3 +1,3 @@
 SELECT @@global.example_enum_var = 'e2';
 @@global.example_enum_var = 'e2'
-1
+0

mysqltest: Result content mismatch

I do not have access to any additional log files right at this moment, but can probably
get them for you tomorrow if you specify what you're interested in.

Also, this happens on released Fedora 10 as well as Fedora rawhide (ie F11-to-be).  It
might happen on older versions too, but those are the only releases I've tried to test
mysql 5.1 on.  As stated, I see it consistently on PPC64 but not PPC, x64, or x86_64 ...
cannot say about other architectures.

Thank you for the feedback.

I changed description of the bug, so it reflects correct situation. Please send us log
files if you can. Also is interesting if this test fails when run not after plugin test,
i.e. ./mysql-test-run.pl plugin_load

var/log/ contents after running /usr/bin/perl ./mysql-test-run.pl plugin_load

Attachment: plugin_load_test.tar.gz (application/x-gzip, text), 1.68 KiB.

Yes, it fails just the same way if I run only that one regression test, which knocks out
my theory about a race condition with the previous test.  (And makes it even more
questionable why the test doesn't result in an error message...)  I have uploaded the
var/log/ files --- is that what you wanted? --- for a run with just that single test
selected.  I also have the log files for the full regression tests up to the point of the
failure, but that's a couple megabytes so I won't upload unless specifically asked for.

Thank you for the update.

Yes, var/log content is what I asked for.

Thank you for the feedback.

Verified as described on AIX 5.3 on PPC64 machine.

The test also fails on Sparc. Due to Bug #45298, the test has been incorrectly skipped,
but after this was fixed in 5.1-mtr and azalea-mtr, the test fails every time:

CURRENT_TEST: main.plugin_load
---
/export/home/pb2/test/sb_1-588409-1245188639.34/mysql-5.1.36-solaris10-sparc-test/mysql-test/r/plugin_load.result	2009-06-17
00:35:54.000000000 +0300
+++
/export/home/pb2/test/sb_1-588409-1245188639.34/mysql-5.1.36-solaris10-sparc-test/mysql-test/r/plugin_load.reject	2009-06-17
00:48:45.533348000 +0300
@@ -1,3 +1,3 @@
 SELECT @@global.example_enum_var = 'e2';
 @@global.example_enum_var = 'e2'
-1
+0

If I modiy the SELECT to actually select the variable in stead of testing that its value
is 'e2' (that's probably how the test should have been in the first place), the test
shows that the value is 'e1'.

This is in PB2, also veryfied my manually running only the plugin_load test on the PB2
binaries. *However*, if I run the test on the same host with binaries I've built myself,
it succeeds!  The configure command for this build is simplistic:

./configure CC=/opt/studio12/SUNWspro/bin/cc CXX=/opt/studio12/SUNWspro/bin/CC
--prefix=/home/bm136801/install/51mtr --with-plugins=myisam,innobase

I am sending this back, it was assigned to me with a suggestion (sent me by email) about a
change in MTR which could fix this.

But this was a red herring, the failure on Sparc is in fact Bug #47146, it just results
in a symptom identical to what this report said. Mea culpa for not seeing this when I
added to this report. If I build with --disable-dtrace, the test succeeds.

I know nothing about the original failure in PPC64 so can't close this as a duplicate,
but I remove "and Sparc" from the synopsis and set OS to Linux.