#58 Failure in MySQLdb.connect(), SEGV

[M. J. Fromberger]

Using MySQLdb 0.9.2 built from CVS (2003.06.26). Got a
clean build using the setup.py modifications described in
698202. However, the following failure occurs (some
details elided by <xx>):

>>> import MySQLdb
>>> c = MySQLdb.connect(db = '<xx>', unix_socket = '/
tmp/mysql.sock', passwd = '<xx>', user = '<xx>')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "MySQLdb/init.py", line 63, in Connect
return apply(Connection, args, kwargs)
File "MySQLdb/connections.py", line 116, in init
self.converter[types.StringType] = self.string_literal
TypeError: object does not support item assignment
>>> ^D
*** malloc[16605]: error for object 0x486290: Incorrect
checksum for freed object - object was probably modified
after being freed; break at szone_error
Segmentation fault

For reference, here is the version info for my freshly-
rebuilt installation of Python:

Python 2.3b1 (#1, Jun 26 2003, 09:38:28)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sys
>>> sys.version
'2.3b1 (#1, Jun 26 2003, 09:38:28) \n[GCC 3.1 20020420
(prerelease)]'
>>> sys.platform
'darwin'
>>> ^D

Is this due to interaction with Python 2.3?

[Andy Dustman]

Logged In: YES
user_id=71372

Try current CVS or upcoming 0.9.3 test releases. I have not
done any Python 2.3 testing yet.

[M. J. Fromberger]

Logged In: YES
user_id=200992

I just updated in CVS and re-built, but I get more or less the
same problem -- just FYI.

[Andy Dustman]

Logged In: YES
user_id=71372

Can you try with MySQL-python-0.9.3a1 and Python-2.3b2? It
may not matter but let me know what version of MySQL you are
using as well.

[Andy Dustman]

Logged In: YES
user_id=71372

I could not replicate with Python 2.3b2, MySQL-4.0.13 on
i386 with GCC 3.2.3. I did make some small changes to remove
some warnings with Python 2.3, so you may try pulling the
latest CVS version (newer than 0.9.3a1). I don't know if the
warnings actually affected anything.

[Rune Hansen]

Logged In: YES
user_id=814334

MySQLdb from cvs , python2.3b2 - Darwin MacOSX 10.2.6

>>> import MySQLdb
>>> from MySQLdb import cursors
>>> conn =
MySQLdb.connect(db="xxx",host="xxx",user="xxx",passwd="xxx"
,cursorclass=cursors.DictCursor)
>>> cur = conn.cursor()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.3/site-packages/MySQLdb/connections.py",
line 92, in cursor
return (cursorclass or self.cursorclass)(self)
File "/usr/lib/python2.3/site-packages/MySQLdb/cursors.py", line
36, in init
self.errorhandler = connection.errorhandler
AttributeError: Connection instance has no attribute 'errorhandler'

[M. J. Fromberger]

Logged In: YES
user_id=200992

Just did a test with Python 2.3b2 and MySQLdb 0.9.3a2, talking
to MySQL 4.0.13 under MacOS X 10.2.6 (Darwin 6.6); results:

>>> import MySQLdb
>>> db = MySQLdb.connect(
... unix_socket = '/tmp/mysql.sock',
... user = '<xx>',
... passwd = '<yy>',
... db = '<zz>')
Traceback (most recent call last):
File "<stdin>", line 5, in ?
File "/sw/lib/python2.3/site-packages/MySQLdb/init.py",
line 63, in Connect
return apply(Connection, args, kwargs)
File "/sw/lib/python2.3/site-packages/MySQLdb/
connections.py", line 116, in init
self.converter[types.StringType] = self.string_literal
TypeError: object does not support item assignment
>>> ^D
Segmentation fault

Same basic issue. Any further info you want? I didn't build
Python with debugging symbols, but I could probably run to
failure in gdb and capture a stack trace, if that would help
(though it looks at least partially memory-related, so the crash
site could be remote from the problem site).

[Rune Hansen]

Logged In: YES
user_id=814334

MacOs X (darwin), Python2.3b2, latest CVS (mon 14.july 2003)
Success! Cleaned out site-packages before build and install. Since
my install from official MySQL.dmg installs to /usr/local/mysql I
have to edit setup.py adding '/usr/local/mysql/lib & include' and
removing '/sw..' else it complains about missing dirs.
Thank you for your great work!

[Andy Dustman]

Logged In: YES
user_id=71372

Michael, can you confirm this?

[M. J. Fromberger]

Logged In: YES
user_id=200992

I'm sad to say that I cannot confirm it; I just now did a clean
build (fresh download from CVS, cleaned out the old stuff from
the site directory, built and installed anew). The same error
occurs as transcripted in my last posting before this.

I'm using Python2.3b2 and MySQL installed via Fink, so
everything is under /sw.

[Andy Dustman]

Logged In: YES
user_id=71372

Can you guys try 0.9.3b2 with Python-2.3 (final)?

[M. J. Fromberger]

Logged In: YES
user_id=200992

I'm still seeing the same problem, unfortunately; I checked out
from CVS this morning, built and installed MySQLdb, and ran the
following test. Did I get the right version? The version string in
setup.py says:

version = "0.9.3a2"

Do I need to specify a different tag when I'm updating from CVS?

Here's a transcript of the results, with sensitive stuff elided by
<xx> as before:

% python
Python 2.3 (#1, Jul 31 2003, 21:42:43)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import MySQLdb
>>> c = MySQLdb.connect(db = '<xx>', unix_socket = '/tmp/
mysql.sock',
... passwd = '<xx>', user = '<xx>')
Traceback (most recent call last):
File "<stdin>", line 2, in ?
File "/sw/lib/python2.3/site-packages/MySQLdb/init.py",
line 63, in Connect
return apply(Connection, args, kwargs)
File "/sw/lib/python2.3/site-packages/MySQLdb/
connections.py", line 116, in init
self.converter[types.StringType] = self.string_literal
TypeError: object does not support item assignment
>>> ^D
*** malloc[23219]: error for object 0x45fec0: Incorrect checksum
for freed object - object was probably modified after being freed;
break at szone_error
Segmentation fault
%

[Kevin Marks]

Logged In: YES
user_id=798552

I worked out what is wrong here. Apple installs headers for mysql
3.5x in /usr/include/mysql despite not installing mysql
When you install 4.0.x the usual way, it doesn't change these, so
the header and libraries being lined are incompatible. I changed
these to a copy of he ones in /usr/local/mysql/include and it
worked fine.

I also had to modify the setup.py like this:

include files and library locations should cover most platforms

include_dirs =
'/usr/include/mysql', '/usr/local/include/mysql',
'/usr/local/mysql/include/mysql', '/usr/local/mysql/include'

library_dirs =
'/usr/lib/mysql', '/usr/local/lib/mysql',
'/usr/local/mysql/lib/mysql', '/usr/local/mysql/lib'

perhaps putting them in this order will fix things:

include files and library locations should cover most platforms

include_dirs =
'/usr/local/mysql/lib', '/usr/include/mysql', '/usr/local/include/
mysql', '/usr/local/mysql/include/mysql'

library_dirs =
'/usr/local/mysql/lib', '/usr/lib/mysql', '/usr/local/lib/mysql',
'/usr/local/mysql/lib/mysql'

alternatively, the installer could seek and remove the old headers
on Macs

[M. J. Fromberger]

Logged In: YES
user_id=200992

The solution posted by kevinmarks works for me. Great! I
didn't even THINK to check for obsolete headers, since
there were no mysql binaries. I really appreciate you
figuring this out.

So, at least for my part, this appears to be fixed: I can
create connections and cursors, and I can muck about with
the data in my tables. I have not done extensive testing of
the interface, but it appears to be working with Python
2.3.1 and MySQL 4.0.15.

As far as building goes, I just renamed Apple's /usr/
include/mysql to /usr/include/mysql.old, and added /sw/
include to include_dirs and /sw/lib to library_dirs in the
MySQLdb setup.py, and everything built as it was
supposed to.

[Maximillian Dornseif]

Logged In: YES
user_id=554460

I see the same error on MacOS 10.2.8 and it seems not to be the
headers:

[c0ldcut:~/code/MySQL-python-0.9.2] md% sudo mv /usr/include/
mysql /usr/include/mysql-obsolete
[c0ldcut:~/code/MySQL-python-0.9.2] md% cat MySQL-python-
0.9.2-fink-compile.patch
--- setup.py.orig Fri Oct 31 21:16:52 2003
+++ setup.py Fri Oct 31 21:16:52 2003
@@ -25,11 +25,11 @@
# include files and library locations should cover most platforms
include_dirs =
'/usr/include/mysql', '/usr/local/include/mysql',
- '/usr/local/mysql/include/mysql'
+ '/usr/local/mysql/include/mysql', '/sw/include/mysql'

library_dirs =
'/usr/lib/mysql', '/usr/local/lib/mysql',
- '/usr/local/mysql/lib/mysql'
+ '/usr/local/mysql/lib/mysql', '/sw/lib/mysql'

# MySQL-3.23 and newer need libz

... apply patch, build, install ...

[c0ldcut:~/code/MySQL-python-0.9.2] md% uname -a
Darwin c0ldcut 6.8 Darwin Kernel Version 6.8: Wed Sep
10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC
Power Macintosh powerpc
[c0ldcut:~/code/MySQL-python-0.9.2] md% python
Python 2.3 (#2, Jul 30 2003, 11:45:28)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import MySQLdb
>>> MySQLdb.connect()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "MySQLdb/init.py", line 63, in Connect
return apply(Connection, args, kwargs)
File "MySQLdb/connections.py", line 116, in init
self.converter[types.StringType] = self.string_literal
TypeError: object does not support item assignment
>>>
*** malloc[26114]: error for object 0x10c5d0: Incorrect checksum
for freed object - object was probably modified after being freed;
break at szone_error
Segmentation fault

I fiddled a bit with MySQLdb/connections.py and found out
self.converter is None. and even if I do self.converter = [] it stays
none.

I was suspecting it was a gcc 3.1/3.3 incompatibility so I ensured
the module and Python where both compiled with gcc 3.1 - but
same problem.

[Maximillian Dornseif]

Logged In: YES
user_id=554460

GOT It!

Its not a MySQL-python Bug. Its a GCC 3.1/3.3 ABI incompatibility
It turns out my libmysql was compiled with gcc3.3, while python
and _mysql where compiled with gcc 3.1.

Recompiling mysql with gcc 3.1 solved the problem.

Changing gcc versions can be archived by using "gcc_select".

[Andy Dustman]

Logged In: YES
user_id=71372

Compiler mismatch.