Bug #43445 Debug server segfaults on Solaris when creating stored proc without current db
Submitted: 6 Mar 2009 9:30 Modified: 6 Mar 2009 11:06
Reporter: Bjørn Munch Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Logging Severity:S3 (Non-critical)
Version:5.1 OS:Solaris
Assigned to: CPU Architecture:Any
Tags: Contribution

[6 Mar 2009 9:30] Bjørn Munch
Description:
I *think* the synopsis is roughly correct regarding the context.

The new MTR by default runs a check_testcase before and after each test. This starts by doing a

CREATE DEFINER=root@localhost PROCEDURE check_testcase()
BEGIN
.....

With --debug, this results in a server segfault, excerpt from the call stack:

---
  [8] strlen(0x8652d59, 0xfe9cad70, 0x87e19d8, 0x0), at 0xfeb0573c 
  [9] vfprintf(0x87e19d8, 0x8652d50, 0xfe9cad70), at 0xfeb60870 
  [10] _db_doprnt_(format = 0x8652d50 "name: '%s'", ... = (nil), ...), line 1161 in "dbug.c"
  [11] mysql_change_db(thd = 0x8958860, new_db_name = 0xfe9caf3c, force_switch = true), line 1527 in "sql_db.cc"
  [12] db_load_routine(thd = 0x8958860, type = 2, name = 0xfe9cbc54, sphp = 0xfe9cbc4c, sql_mode = 0, params = 0x8667ffc "", returns = 0x8667ffd "", body = 0x8980f68 "BEGIN    SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES     WHERE variable_name != 'timestamp' ORDER BY VARIABLE_NAME;    SELECT * FROM INFORMATION_SCHEMA.SCHEMATA;    SELECT table_name AS tables_in_test FROM INFORMATION_SCHEMA.TABLES     WHERE table_schema='test';    SELECT CONCAT(table_schema, '.', table_name) AS tables_in_mysql     FROM INFORMATION_SCHEMA.TABLES       WHERE table_schema='mysql' AND table_name != 'ndb_apply_status'         ORDER BY tables_in_mysql;   SELECT CONCAT(table_schema, '.', ta" ..., chistics = STRUCT, definer = 0x89814b0 "root@localhost", created = 20090306121952LL, modified = 20090306121952LL, creation_ctx = 0x8981510), line 634 in "sp.cc"
  [13] db_find_routine(thd = 0x8958860, type = 2, name = 0xfe9cbc54, sphp = 0xfe9cbc4c), line 505 in "sp.cc"
---

I had to remove three DBUG_PRINT statements to get this simple test to run:

---
=== modified file 'sql/handler.cc'
--- sql/handler.cc      2009-01-30 13:44:49 +0000
+++ sql/handler.cc      2009-03-06 08:49:41 +0000
@@ -3792,8 +3792,6 @@
 {
   int error= 0;
   DBUG_ENTER("ha_find_files");
-  DBUG_PRINT("enter", ("db: '%s'  path: '%s'  wild: '%s'  dir: %d", 
-                      db, path, wild ? wild : "NULL", dir));
   st_find_files_args args= {db, path, wild, dir, files};
 
   plugin_foreach(thd, find_files_handlerton,

=== modified file 'sql/sql_db.cc'
--- sql/sql_db.cc       2009-01-23 12:22:05 +0000
+++ sql/sql_db.cc       2009-03-06 08:47:39 +0000
@@ -1524,7 +1524,6 @@
   CHARSET_INFO *db_default_cl;
 
   DBUG_ENTER("mysql_change_db");
-  DBUG_PRINT("enter",("name: '%s'", new_db_name->str));
 
   if (new_db_name == NULL ||
       new_db_name->length == 0)

=== modified file 'sql/sql_show.cc'
--- sql/sql_show.cc     2009-01-23 12:22:05 +0000
+++ sql/sql_show.cc     2009-03-06 08:48:08 +0000
@@ -3437,9 +3437,6 @@
 
   if (get_lookup_field_values(thd, cond, tables, &lookup_field_vals))
     DBUG_RETURN(0);
-  DBUG_PRINT("INDEX VALUES",("db_name='%s', table_name='%s'",
-                             lookup_field_vals.db_value.str,
-                             lookup_field_vals.table_value.str));
   if (make_db_list(thd, &db_names, &lookup_field_vals,
                    &with_i_schema))
     DBUG_RETURN(1);

---

I do NOT get the same crash with 6.0.  Also, if I add option --no-check-test is doesn't crash, at least with this test.

This may be the same as Bug #37850 but thet report is not detailed enough to be sure.

How to repeat:
On debug server built with Sun Studio:

./mtr --debug alias
[6 Mar 2009 9:33] Bjørn Munch
Just a short followup: vprintf() in glibc does accept null pointers as string arguments, that's why it doesn't crach on Linux.  Solairs libc does not.
[6 Mar 2009 11:06] Sveta Smirnova
Thank you for the report.

Test alias starts with DROP/CREATE TABLE statements exactly like in case of bug #37850. Additionally I remember almost any statement did same behavior. So I close this report as duplicate of bug #37850