MySQL Bugs: #24548: Unable to load UDF example

Bug #24548	Unable to load UDF example
Submitted:	23 Nov 2006 15:19	Modified:	7 Jan 2007 8:51
Reporter:	Paul Carlton	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: User-defined functions ( UDF )	Severity:	S3 (Non-critical)
Version:	5.1.11 and 5.1.12	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
I have built mysql using...

./configure --prefix=/hptc_cluster/paul/mysql-5.1.11 --with-plugins=max --with-mysqld-ldflags=-rdynamic
make
make install

The startup command I used was...

mysqld_safe --user=mysql --server-id=50 --port=33306 --pid-file=pid50 --skip-innodb --socket=$PWD/var/sock50 --log=$PWD/var/my50.log --event-scheduler=ON --plugin_dir=$PWD/lib/mysql &

I place my own and the example UDF .so files in the lib/mysql directory referred to by the plugin_dir variable.  I was unable to create the function, kept getting 'error 22 cannot open shared object file: No such file or directory'. Then I tried placing the .so files in /usr/lib and that worked on my development system (using 5.1.11)...

Linux pcarlton1 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 i686 i386 GNU/Linux

However, when I repeated the process on two other 64 bit systems I got the error 22 problem, even when adding the .so files to /usr/lib.

Linux n5 2.6.9-22.7hp.1sp.XCsmp #1 SMP Thu Mar 23 21:35:55 EST 2006 x86_64 x86_64 x86_64 GNU/Linux

Then I tried to create a UDF.  Despite the adding the .so files to /usr/lib

How to repeat:
Install 5.1.11 on a 64 bit system and build from source then try to create a function using udf_example.so

Thank you for a problem report. Have you tired to repeat with 5.1.12? I see it in version feild, but you refer to 5.1.11 only in description.

Yes, tried it with 5.1.11 and 5.1.12 on two 64 bit systems.  Only tried it with 5.1.11 on my dev box - where it works ok.

try to strace the server to see what file it tries to load, it often helps

I've run strace on my development system where it loads ok and both the 64 bit SMPs where it does not.  The development system is running 5.1.11 and one of the SMPs is using 5.1.11 and the other is using 5.1.12.  I've uploaded these files, there is no trace of the library being loaded in the other two - look for measperf.so.

strace from development node where it works ok

Attachment: trace5-1-11-ok.log (application/octet-stream, text), 64.92 KiB.

strace from 64 bit SMP where it doesn't work

Attachment: trace5-1-12-smp64.log (application/octet-stream, text), 61.04 KiB.

strace from 64 bit SMP where it doesn't work - running 5.1.11

Attachment: trace-5-1-11-smp64.log (application/octet-stream, text), 73.62 KiB.

According to strace mysql.func table is empty on your 64but SMP boxes and not empty on your development box.

Yes, that is right, on the development system some functions have already been added, whilst on the SMP we are unable to do so.

But then it's useless to strace mysqld startup. You want to strace how MySQL tries to load the udf to see why it fails. If MySQL doesn't even try to load anything (because mysql.func table is empty) there's no sense to strace.
So, either strace MySQL during CREATE FUNCTION statement, or insert the row directly into mysql.func (with INSERT), and then strace mysqld startup.

All three traces include startup plus an attempt to create a function.  In the case of my development system I dropped a function first.

There's nothing in the trace that indicates an attempt to create a function. perhaps strace wasn't able to trace the created threads.
Le'ts try to do all on startup - that is, INSERT the necessary line into mysql.func table (or copy it from your development system), and strace the startup.

I've worked around this problem by implementing my functions as native functions.  I'll try out your suggestion but probably not until I've completed some time critical tasks , thanks.

Please also try to add directory where your UDF *.so files are located to LD_LIBRARY_PATH and then try to create function.

You can do it in bash using command `export LD_LIBRARY_PATH=/path/to/plugin/files:$LD_LIBRARY_PATH`

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".