The output is pretty simple too:
linux:~/MySQL-python-1.2.1_p2 # python simple-test.py
Segmentation fault
linux:~/MySQL-python-1.2.1_p2 #
I tried it with gdb, although I honestly don't know what I'm doing with gdb
linux:~/MySQL-python-1.2.1_p2 # gdb --args python simple-test.py
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /usr/local/bin/python simple-test.py [Thread debugging using libthread_db enabled] [New Thread 182905146752 (LWP 31107)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182905146752 (LWP 31107)]
0x0000002a95e322b5 in free () from /lib64/tls/libc.so.6
(gdb) info symbol 0x0000002a95e322b5
free + 37 in section .text
(gdb)
Mind you, I have no real idea what these values mean. But it looks like there's some memory access issues whenever you attempt to close the Mysql connection in Python. I was able to make the error disappear by commenting out the C which actually closes the connection in _mysql.c,
686: mysql_close(&(self->connection));
... but somehow I don't think that's the solution I'm looking for. Hopefully somebody here has some useful advice beyond "upgrade your distro." Much as I would like to, that probably isn't an option for this work machine.
Thanks in advance,
Brian Wisti
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The numbers means nothing. I will say that I can't reproduce on Gentoo amd64 and MySQL-5.0.18. See if your library versions are any different from mine.
That <value optimized out> business seems suspicious. Can you find out what optimization level is being used to compile _mysql.c, i.e. -O2, -O3, etc.? You can probably find this in /usr/lib64/python2.4/config/Makefile, or get rid of your build directory and rebuild. It looks like you have GCC-3.3.3. I'm probably using GCC-3.4.5 on my amd64 box. You may be hitting an optimization bug. It doesn't help though that your MySQL seems to have limited debugging support.
Based on your backtrace, though, I do not think this can be an issue in MySQLdb/_mysql.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We're taking a look at grabbing a different distro, rather than using the suse 9 that we're on right now. Especially since the code seems to work lovely on every other machine.
For now, though, should I adjust the optimization level?
Here's some hopefully relevant info about my platform.
linux:~/MySQL-python-1.2.1_p2 # cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9
PATCHLEVEL = 3
linux:~/MySQL-python-1.2.1_p2 # python
Python 2.4.3 (#1, Apr 21 2006, 13:09:53)
[GCC 3.3.3 (SuSE Linux)] on linux2
linux:~/MySQL-python-1.2.1_p2 # mysql --version
mysql Ver 14.12 Distrib 5.0.20, for unknown-linux-gnu (x86_64) using readline 5.0
I'm trying to figure out why my Python Mysql code segfaults on every run. I've whittled it down to the most basic script I could think of below:
linux:~/MySQL-python-1.2.1_p2 # cat simple-test.py
!/usr/bin/python
import MySQLdb
conn = MySQLdb.Connect(host="localhost", user="xxx", passwd="xxx", db="xxx")
conn.close()
The output is pretty simple too:
linux:~/MySQL-python-1.2.1_p2 # python simple-test.py
Segmentation fault
linux:~/MySQL-python-1.2.1_p2 #
I tried it with gdb, although I honestly don't know what I'm doing with gdb
linux:~/MySQL-python-1.2.1_p2 # gdb --args python simple-test.py
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /usr/local/bin/python simple-test.py
[Thread debugging using libthread_db enabled]
[New Thread 182905146752 (LWP 31107)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182905146752 (LWP 31107)]
0x0000002a95e322b5 in free () from /lib64/tls/libc.so.6
(gdb) info symbol 0x0000002a95e322b5
free + 37 in section .text
(gdb)
Mind you, I have no real idea what these values mean. But it looks like there's some memory access issues whenever you attempt to close the Mysql connection in Python. I was able to make the error disappear by commenting out the C which actually closes the connection in _mysql.c,
686: mysql_close(&(self->connection));
... but somehow I don't think that's the solution I'm looking for. Hopefully somebody here has some useful advice beyond "upgrade your distro." Much as I would like to, that probably isn't an option for this work machine.
Thanks in advance,
Brian Wisti
The numbers means nothing. I will say that I can't reproduce on Gentoo amd64 and MySQL-5.0.18. See if your library versions are any different from mine.
$ ldd build/lib.linux-x86_64-2.4/_mysql.so
libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15 (0x00002aaaaabdd000)
libz.so.1 => /lib/libz.so.1 (0x00002aaaaae2c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002aaaaaf40000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002aaaab056000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002aaaab18a000)
libm.so.6 => /lib/libm.so.6 (0x00002aaaab2a0000)
libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x00002aaaab427000)
libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x00002aaaab55e000)
libc.so.6 => /lib/libc.so.6 (0x00002aaaab79e000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab9c4000)
Also, in site.cfg, add extra_compile_args = -g That will add debugging symbols. Then when it crashes in gdb, use bt to produce a backtrace.
linux:~/MySQL-python-1.2.1_p2 # ldd build/lib.linux-x86_64-2.4/_mysql.so
libmysqlclient.so.15 => /usr/lib64/libmysqlclient.so.15 (0x0000002a9566e000)
libz.so.1 => /lib64/libz.so.1 (0x0000002a958c3000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000002a959d6000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000002a95b0f000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95c25000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a95d7d000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95e92000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
linux:~/MySQL-python-1.2.1_p2 #
Library information seems to be pretty much the same at a casual glance. I don't know how much of the backtrace you need, though.
0 0x0000002a95e322b5 in free () from /lib64/tls/libc.so.6
1 0x0000002a9612655e in my_no_flags_free () from /usr/lib64/libmysqlclient.so.15
2 0x0000002a96148b60 in mysql_select_db () from /usr/lib64/libmysqlclient.so.15
3 0x0000002a96148bfc in mysql_close () from /usr/lib64/libmysqlclient.so.15
4 0x0000002a95ff6a83 in _mysql_ConnectionObject_close (self=0x6d9ed0, args=<value optimized out>) at _mysql.c:686
5 0x00000000004de45c in PyCFunction_Call (func=0x2a96b604d0, arg=0x2a9556d050, kw=<value optimized out>) at methodobject.c:93
6 0x0000000000486526 in PyEval_EvalFrame (f=0x64aad0) at ceval.c:1499
7 0x0000000000487c0b in PyEval_EvalCodeEx (co=0x2a955b9e30, globals=<value optimized out>, locals=<value optimized out>,
8 0x0000000000487e82 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>)
9 0x00000000004b7441 in PyRun_SimpleFileExFlags (fp=0x647010, filename=<value optimized out>, closeit=1, flags=0x7fbfffe1f4)
10 0x0000000000410a41 in Py_Main (argc=1, argv=0x7fbfffe3b8) at main.c:493
11 0x0000002a95de5aaa in __libc_start_main () from /lib64/tls/libc.so.6
12 0x000000000041002a in _start () at start.S:113
everything after is 0x<value> in ?? () for many lines
... then this at the very end.
919 0x006e6f687479702f in ?? ()
920 0x0000000000000000 in ?? ()
Cannot access memory at address 0x7fc0000000
(gdb)
If you want, I can give you the full output of bt.
That <value optimized out> business seems suspicious. Can you find out what optimization level is being used to compile _mysql.c, i.e. -O2, -O3, etc.? You can probably find this in /usr/lib64/python2.4/config/Makefile, or get rid of your build directory and rebuild. It looks like you have GCC-3.3.3. I'm probably using GCC-3.4.5 on my amd64 box. You may be hitting an optimization bug. It doesn't help though that your MySQL seems to have limited debugging support.
Based on your backtrace, though, I do not think this can be an issue in MySQLdb/_mysql.
Looks to be 'O3'
We're taking a look at grabbing a different distro, rather than using the suse 9 that we're on right now. Especially since the code seems to work lovely on every other machine.
For now, though, should I adjust the optimization level?
...
creating build/temp.linux-x86_64-2.4
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/mysql -I/usr/local/include/python2.4 -c _mysql.c -o build/temp.linux-x86_64-2.4/_mysql.o -g -Dversion_info="(1,2,1,'final',2)" -Dversion="1.2.1_p2"
gcc -pthread -shared build/temp.linux-x86_64-2.4/_mysql.o -L/usr/lib64/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread -o build/lib.linux-x86_64-2.4/_mysql.so
Edit site.cfg and set extra_compile_args to -O2 or -O1.