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

[9 Jul 2005 14:23] Jan Kneschke
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.
[9 Jul 2005 15:43] MySQL Verification Team
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>
[27 Jan 2006 12:01] Sergey Vojtovich
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
[3 Feb 2006 3:29] Brian Aker
Please have someone add this to the test case system to test in the future.
[24 Feb 2006 15:01] Magnus Blåudd
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.
[24 Feb 2006 16:50] Magnus Blåudd
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.
[27 Feb 2006 8:32] Magnus Blåudd
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            *
  ***************************************************************
[28 Feb 2006 9:18] Magnus Blåudd
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
[10 Mar 2006 8:51] Bugs System
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
[11 Mar 2006 8:54] Parul Vipparthi
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.
[13 Mar 2006 8:19] Magnus Blåudd
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.
[22 Mar 2006 11:28] Magnus Blåudd
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.
[22 Mar 2006 17:13] Mike Hillyer
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>

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.070 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.