MySQL Bugs: #11804: Segfaults everywhere on Amd64

Bug #11804	Segfaults everywhere on Amd64
Submitted:	8 Jul 2005 3:57	Modified:	25 Jul 2006 20:03
Reporter:	[ name withheld ]	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Administrator	Severity:	S1 (Critical)
Version:	1.1.5	OS:	Linux (Linux/Debian)
Assigned to:	Alfredo Kojima	CPU Architecture:	Any
Tags:	Generic

Description:
Hi,

This is a forwarded bug from the debug BTS #317371 found at,
http://bugs.debian.org/317371

The reporter writes:
  I just installed the package "mysql-admin" and accepted the dependencies in the synaptic package-manager in order to access a remote mysql 4.0.24 Database on a  Debian/sarge Box. The installations seems to be fine. The Programm starts and i can log-in to my database. When i klick on "User Administration" or "Server Connections" the program stops with segfault. 
  When i Call "Backup" and then press "New Project" I can see and select my Databases - when i press the to-the-right-arrow ( -> ) the programm stops with segfault.

How to repeat:
see above.

Suggested fix:
The probable cause of these error are casts of (void*) <-> (int) that I find everywhere. It is NOT SAFE to cast a pointer to an integer and vice-versa. These are not guaranteed to be the same size. If you need a pointer, use a pointer. If you need an int, use that. DO NOT mix pointers with integers.

I've already filed a bug against mysql-query-browser that seems similar.
http://bugs.mysql.com/bug.php?id=11751
The casts there are very questionable. My patch for that bug just recasts things to avoid compiler errors. If you do

void *data = (void*)boolean_value;
my_func( data );

and then in the function,
void my_func( void * data )
{
  bool a = (bool)data;
}

Then this is OK because you never use a "pointer" and data size is always less than either sizeof(void*) or sizeof(int), but if you try

void *data;
my_func( (int)data );

void my_func( int d )
{
   void *data = (void*)d;  <--- CANNOT do this!!! sizeof(int) < sizeof( void*)
}

then this is just wrong.

oops, corrected the version number

Here are the segfaults that I forward. mysql-admin compiled with debug symbols and run under a debugger. I truncated virtually all backtraces since the stacks seem to be corrupt.

When I start mysql-admin and Log in to my Database everything seems to be OK.
When I klick at "User Administration" the Application sigfaults instantly.

The Backtrace: -----------------------------------------------------------------------

(gdb) bt
#0  0x0000002a956a77e4 in mysql_select_db () from /usr/lib/libmysqlclient_r.so.14
#1  0x00000000005027b4 in myx_use_schema (mysql=0x0, schema=0x2 <Address 0x2 out of bounds>) at myx_library.c:705
#2  0x00000000005002f9 in use_schema_store_old_one (mysql=0x9fc5c0, schema_name=0x9a17f8 "feuwe", old_schema_name=0x407ff7b0) at myx_catalogs.c:105
#3  0x00000000005003b1 in myx_get_schema_tables (mysql=0x9fc5c0, catalog_name=0x2 <Address 0x2 out of bounds>, schema_name=0x9a17f8 "feuwe")
    at myx_catalogs.c:149
    #4  0x0000000000425e25 in fetch_data3 (data=0x5) at MInstanceInfo.cc:399
    #5  0x00000000004d982e in MDispatcher::thread_func (self=0xa42300) at MDispatcher.cc:39
    #6  0x0000002a95be8b55 in start_thread () from /lib/libpthread.so.0
    #7  0x0000002a980777f0 in clone () from /lib/libc.so.6
    #8  0x0000000000000000 in ?? ()
    #9  0x0000000000000000 in ?? ()
    #10 0x0000000000000000 in ?? ()

When I start mysql-admin and Log in to my Database everything seems to be OK.
When I click at "Backup" the Application and than the "New Projekt" button my
Databases switch from grey-color to orange-color so that i can click at one DB.
The selected DB is marked. When i click the orange arrow the Programm segfaults.

I can't backtrace the Programm because in gdb the behavior is not the same than outside.
In real-live i can produce the segfaults like described above. In GDB the Program stops 
responding before reaching the point where the segfault happens. The GDB-Output: 

-------------------------------------------------------------------------------------------
(gdb) run
Starting program: /home/carsten/temp/mysql-admin-1.0.20/mysql-administrator/source/linux/mysql-administrator-bin
[Thread debugging using libthread_db enabled]
[New Thread 182954617744 (LWP 16629)]
[New Thread 1082128752 (LWP 16632)]
[Thread 1082128752 (LWP 16632) exited]
[New Thread 1082128752 (LWP 16689)]
[Thread 1082128752 (LWP 16689) exited]
[New Thread 1082128752 (LWP 16690)]
[Thread 1082128752 (LWP 16690) exited]
[New Thread 1082128752 (LWP 16692)]
[Thread 1082128752 (LWP 16692) exited]
ptrace: Kein passender Prozess gefunden.
thread_db_get_info: cannot get thread info: generic error
(gdb)
-------------------------------------------------------------------------------------------
The last who lines where added when the Programm stops responding.
To help you: The line "Kein passender Prozess gefunden." is german and
means: "No matching process (was) found."

When I start mysql-admin and Log in to my Database everything seems to be OK.
When I klick at "Cataloges" i see my Databases. If i select one the 
Application sigfaults instantly.

The Backtrace: -----------------------------------------------------------------------

(gdb) bt
#0  0x0000002a956a77e4 in mysql_select_db () from /usr/lib/libmysqlclient_r.so.14
#1  0x00000000005027b4 in myx_use_schema (mysql=0x0, schema=0x2 <Address 0x2 out of bounds>) at myx_library.c:705
#2  0x00000000005002f9 in use_schema_store_old_one (mysql=0x9fbbe0, schema_name=0x9a18f8 "spowe", old_schema_name=0x407ff7b0) at myx_catalogs.c:105
#3  0x00000000005003b1 in myx_get_schema_tables (mysql=0x9fbbe0, catalog_name=0x2 <Address 0x2 out of bounds>, schema_name=0x9a18f8 "spowe")
    at myx_catalogs.c:149
    #4  0x0000000000425e25 in fetch_data3 (data=0x5) at MInstanceInfo.cc:399
    #5  0x00000000004d982e in MDispatcher::thread_func (self=0xb22460) at MDispatcher.cc:39
    #6  0x0000002a95be8b55 in start_thread () from /lib/libpthread.so.0
    #7  0x0000002a980777f0 in clone () from /lib/libc.so.6
    #8  0x0000000000000000 in ?? ()
    #9  0x0000000000000000 in ?? ()
    #10 0x0000000000000000 in ?? ()

When I start mysql-admin and Log in to my Database everything seems to be OK.
When i click at "Restore" i can change the directory where my backups are stored.
I can choose a backup to restore but when i click at "Restore" the
Application sigfaults instantly.

The Backtrace: -----------------------------------------------------------------------

(gdb) bt
#0  0x0000002a956a77e4 in mysql_select_db () from /usr/lib/libmysqlclient_r.so.14
#1  0x00000000005027b4 in myx_use_schema (mysql=0x0, schema=0x2 <Address 0x2 out of bounds>) at myx_library.c:705
#2  0x00000000005002f9 in use_schema_store_old_one (mysql=0x9fbb90, schema_name=0xa98310 "postfix", old_schema_name=0x7fbfffdac0) at myx_catalogs.c:105
#3  0x00000000005003b1 in myx_get_schema_tables (mysql=0x9fbb90, catalog_name=0x2 <Address 0x2 out of bounds>, schema_name=0xa98310 "postfix")
    at myx_catalogs.c:149
    #4  0x00000000004a3000 in myx_get_restore_drop_list (mysql=0x9fbb90, content=0xa9e7f0) at myx_backup.c:2499
    #5  0x0000000000488ffe in MARestorePanel::check_tables_to_be_dropped (this=0x865230, content=0x2) at MInstanceInfo.h:58
    #6  0x000000000048938a in MARestorePanel::perform_restore (this=0x865230) at MARestorePanel.cc:658
    #7  0x000000000048ada4 in SigC::ObjectSlot0_<void, MARestorePanel>::proxy (s=0x0) at object_slot.h:62
    #8  0x0000002a96d2caec in Glib::SignalProxyNormal::slot0_void_callback () from /usr/lib/libglibmm-2.0.so.1
    #9  0x0000002a9780dd22 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
    #10 0x0000002a977fe056 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
    #11 0x0000002a9780d767 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
    #12 0x0000002a9780c906 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
    #13 0x0000002a9780cbd3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
    #14 0x0000002a96837c1c in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0
    #15 0x0000002a96838836 in _gtk_button_paint () from /usr/lib/libgtk-x11-2.0.so.0
    #16 0x0000002a9780dd22 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
    #17 0x0000002a977fe2d0 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
    #18 0x0000002a977fe056 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
    #19 0x0000002a9780d182 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
    #20 0x0000002a9780c906 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
    #21 0x0000002a9780cbd3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
    #22 0x0000002a96837bbc in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0
    #23 0x0000002a968386f9 in _gtk_button_paint () from /usr/lib/libgtk-x11-2.0.so.0
    #24 0x0000002a968e0593 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
    #25 0x0000002a977fe2d0 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
    #26 0x0000002a977fe056 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
    #27 0x0000002a9780d37a in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
    #28 0x0000002a9780c713 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
    #29 0x0000002a9780cbd3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
    #30 0x0000002a969af626 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0
    #31 0x0000002a968df0e5 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
    #32 0x0000002a968de2b2 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
    #33 0x0000002a96f90c53 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
    #34 0x0000002a97b5694c in g_main_depth () from /usr/lib/libglib-2.0.so.0
    #35 0x0000002a97b578e4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
    #36 0x0000002a97b57bee in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
    #37 0x0000002a97b580d5 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
    #38 0x0000002a968ddc81 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
    #39 0x0000002a9632a579 in Gtk::Main::run_impl () from /usr/lib/libgtkmm-2.0.so.1
    #40 0x0000002a9632a3b4 in Gtk::Main::run () from /usr/lib/libgtkmm-2.0.so.1
    #41 0x00000000004471d3 in main (argc=1, argv=0x7fbffff7e8) at main.cc:491
    (gdb)

Just to add, the program works perfectly in a 32-bit chroot on Amd64 (32-bit version of mysql-admin, of course :)

I was able to reproduce this bug using FC4 under AMD64.

I have the same problems. My system is Debian on AMD64. I would have done some traces but bug poster has already done so (and very thoroughly might I add).

I was able to confirm this behavior on Ubuntu 5.04 running on AMD32.  Connecting to a server, going to "User Administration", and then clicking on a username gives an error "Could not retrieve user information from server MySQL Error Nr. 0"

Testing on SuSE9.3/AMD64

I have built and tested MA 1.1.4 and 1.0.20 on SuSE9.3 x86_64
Neither 1.0.20 nor 1.1.4 did exibit the problem and seemed to work ok.

I will see if I can get access to a Debian/64bit machine and test it.

I'm guessing it will depend on what compiler you use. If you produce 32-bit executable, yes, it will work perfecly on Amd64. If you produce a native 64-bit executable, then that is where the segfaults occur.

Debian's AMD64 port is a pure 64-bit environment. I'm not sure about Suse or RedHat, but you may need to specify manually what compier to use in the configure script if a 32-bit one is used instead of the 64-bit.

A user reports the following, easy to track down segfault on Amd64,

1. Start "mysql-admin"
2. Login
3. Select "Startup Parameters"
4. Click "Cancel"

Then mysql-admin crashes with the following info:
*** glibc detected *** free(): invalid pointer: 0x0000000000b37a95 ***
Aborted

As youj can see, the pointer seems to have been casted to an int somewhere. On 64-bit platforms, sizeof(int) == 4 while sizeof(void*) == 8, hence the problems with zeros and invalid pointers.

Please try this binary in an AMD64 machine, I can't give it a thorough testing because I only have very slow remote access to a faraway machine.
ftp://ftp.mysql.com/pub/mysql/download/mysql-administrator-1.1.6pre1-unknown-linux-x86_64....

Tried the mysql-administrator-1.1.6pre1-unknown-linux-x86_64.tar.gz and still crashed.

Steps:

1. Start mysql-administrator
2. Create Schema
3. Click on Schema
crash

System: Ubuntu Breezy
Linux 2.6.15-ck2 #1 SMP Tue Jan 24 10:10:53 EST 2006 x86_64 GNU/Linux

MySQL 4.0.24

I tried the most recent version 1.1.6 on SUSE 9.3. 
(Kernel: Linux 2.6.11.4-21.11-smp, MySQL Client V 5.0.16 /  with AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ 2412.395 MHz )

This version still produces a segmentation fault when e.g. calling user administration. This is very frustrating.  Why isn't this bug fixed for the 64Bit architecture? 

Kind regards
Ralph

Regarding my last mail: 
I should in addition mention that I tried a connection from the 64Bit Suse 9.3 machine to a SLES 9 server with MySQL 4.0.18. 
The SLES 9 server runs on a 32Bit Intel architecture.

What about the latest version 1.1.10? I have just tried it on SuSE 9.3,  single-core Opteron, which seemed to work.

I've fixed some crashes and bugs I got while testing MA on a AMD64 machine, esp.
on catalogs, user administration and backup/restore.