MySQL Bugs: #11835: CREATE FUNCTION crashes server

Bug #11835	CREATE FUNCTION crashes server
Submitted:	9 Jul 2005 14:23	Modified:	22 Mar 2006 17:12
Reporter:	Jan Kneschke	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: User-defined functions ( UDF )	Severity:	S3 (Non-critical)
Version:	4.1.18, 5.0.19, 5.1.6	OS:	Linux (Linux/x86)
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
CREATE FUNCTION metaphon RETURNS STRING SONAME 'udf_example.so'

leads to a crash:

valgrind says:
==26787==
==26787== Invalid read of size 4
==26787==    at 0x83C4C58: _dl_lookup_versioned_symbol (do-lookup.h:52)
==26787==    by 0x83E210F: _dl_relocate_object (../sysdeps/i386/dl-machine.h:333)
==26787==    by 0x83C6B5E: dl_open_worker (dl-open.c:294)
==26787==    by 0x83C6089: _dl_catch_error (dl-error.c:152)
==26787==    by 0x83C6DE1: _dl_open (dl-open.c:411)
==26787==    by 0x83916B5: dlopen_doit (dlopen.c:39)
==26787==    by 0x83C6089: _dl_catch_error (dl-error.c:152)
==26787==    by 0x83919B5: _dlerror_run (dlerror.c:130)
==26787==    by 0x83916E4: dlopen (dlopen.c:53)
==26787==    by 0x81780F4: mysql_create_function(THD *, st_udf_func *) (sql_udf.cc:434)
==26787==    by 0x80BA73B: mysql_execute_command(THD *) (sql_parse.cc:3617)
==26787==    by 0x80BE88D: mysql_parse(THD *, char *, unsigned int) (sql_parse.cc:5327)
==26787==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

How to repeat:
compile udf_example.so and try the CREATE FUNCTION calls.

http://dev.mysql.com/doc/mysql/en/udf-compiling.html

This worked fine in 5.0.3.

Suggested fix:
fix the crash.

miguel@hegel:/share/dbs/5.0$ bin/mysql -uroot
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.10-beta-debug

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME 'udf_example.so';
Query OK, 0 rows affected (0.06 sec)

mysql> select metaphon("who are you");
+-------------------------+
| metaphon("who are you") |
+-------------------------+
| WRY                     |
+-------------------------+
1 row in set (0.07 sec)

mysql>

I was able to repeat this bug using mypluglib.so from 5.1 (it is in plugin/fulltext):
mysqltest: At line 1: query 'CREATE FUNCTION dummy_function_name RETURNS STRING SONAME 'mypluglib.so'' failed: 2013: Lost connection to MySQL server during query

To make it happend build tree using BUILD/compile-pentium, that is static build.

Was able to repeat in 4.1.18, 5.0.19, 5.1.6.

Note that trying to create function from libc.so.6 works just fine (returns correct error):
mysqltest: At line 2: query 'CREATE FUNCTION dummy RETURNS STRING SONAME 'libc.so.6'' failed:1127: Can't find symbol 'dummy' in library

Also affects INSTALL PLUGIN statement:
mysqltest: At line 1: query 'INSTALL PLUGIN dummy SONAME 'mypluglib.so'' failed: 2013: Lost connection to MySQL server during query

Please have someone add this to the test case system to test in the future.

Reproduced. 
Compiled with BUILD/compile-pentium which makes it impossible for "udf_example.so" to access global variables in mysqld(for example my_charset_latin1). When udf_example.cc was modified not to depend on global vars in mysqld it will load - and crash the server.

The crash pccurs inside 'dlopen' and it seems like dlopen is not supported from a statically linked executable. This mean that we should probably disable this part of the code by undefining HAVE_DLOPEN if static linking is used. At least with glibc.

There is also the following problem, but at least that can be fixed by modifying the plugin:

http://lists.gnu.org/archive/html/bug-glibc/2005-02/msg00085.html
 ***************************************************************
  * problem : from a STATIC executable , dlopen() cannot  link  *
  * if exists some "extern" variable in  the shared lib to link *
  * with some global  variable of the main programme            *
  ***************************************************************

We probably need to use the libtool macro AC_LIBTOOL_DLOPEN before AC_PROG_LIBTOOL. In that way libtool will check for us if  'dlopen' is supported or not.

See the Libtool manual:
http://www.gnu.org/software/libtool/manual.html#Dlopened-modules

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/3683

This function causes server crash version 5.0.18
used Query Browser to create this function

DELIMITER $$

DROP FUNCTION IF EXISTS `mis`.`func111` $$
CREATE FUNCTION `mis`.`func111` () RETURNS INT
BEGIN
  return 12;
END $$

DELIMITER ;

It gave an error like "mysql error could not fetch catalog schemata data, my sql server has gone away"
It also tried to open a vb bug editor.
I would appreciate a solution which is a work around and need not re install the server.

Parul, thanks for your bug report. Unfortunately it's not related to this bug. I've created a separate bug#18179, so please have a look at that and fill in any other findings you may have.

Pushed a fix to 5.0.20 and 5.1.8 that disables support for 'dlopen' if mysqld is linked static. Thereby disabling support for udf's at the same time.

A user that whishes to use udf's need to use a dynamiccally linked mysqld, just as it says in the manual.

Documented: 

  <listitem>
        <para>
          Loading of UDFs in a statically linked MySQL caused a server
          crash. UDF loading is now blocked if the MySQL server is
          statically linked. (Bug #11835)
        </para>
      </listitem>