#34 connect() crash with read_default_file

[Richard Cook]

Using python 1.5.2 on IRIX 6.5, if I use the following
code:
self.mConnection =
MySQLdb.connect(read_default_group='TSB')
I get a Segmentation Fault.
Using python 2.1.1 on IRIX 6.4, I get no seg fault and the
code acts as expected. Upgrading from python 1.5.2 is
problematic since it is built into an executable and would
require potentially extensive work to upgrade.

[Andy Dustman]

Logged In: YES
user_id=71372

Can you try this on a different platform, like i386 Linux?
Otherwise I'm not sure I can fix this. It might even be a
Python 1.5.2 bug.

[Richard Cook]

Logged In: YES
user_id=346175

I may possibly be able to test this with Linux, but it's a bit
difficult. If you have a Linux box with a MySQLdb-enabled
Python 1.5.2, it is very easy to reproduce: simply try the
connect command with the read_default_group parameter.
You don't even need a remote server to be running; the code
will just crash. Are you unable to test this at all or reproduce
it? Please let me know if you require the Linux test, thanks.

[Andy Dustman]

Logged In: YES
user_id=71372

You don't happen to be able to produce some kind of
backtrace from whatever debugger it is you have?

If it only happens with 1.5.2, I'm really inclined to
believe that it's a python bug, but at least a backtrace
will help me decide.

I can't reproduce this presently; I tried your test and it
connected fine, and didn't crash later (like on exit). My
environment is:

Red Hat Linux 7.3 i386 (Pentium-III)
Python-1.5.2 (stock RH)
MySQL-3.23.49 (mysql.com RPMs)
MySQL-python-0.9.2c1 (basically identical to b2)

[Richard Cook]

Logged In: YES
user_id=346175

Does this help? I'm trying and having trouble making our
debug version of this, but I think it may be equally inscrutable.

jackal 31% dbx bin/python
dbx version 7.3.1 68542_Oct26 MR Oct 26 2000 17:50:34
Executable /u1/rcook/TSB/build/build-new/ascivis_source/
bin/python
(dbx) run
Process 481727 (python) started
Python 1.5.2 (#5, Mar 20 2002, 13:32:15) [C] on irix646
Copyright 1991-1995 Stichting Mathematisch Centrum,
Amsterdam
>>> import MySQLdb
>>> x = MySQLdb.connect(read_default_file='/u1/rcook/
.my.cnf')
Process 481727 (python) stopped on signal SIGSEGV:
Segmentation violation (default) at [<unknown>:0
,0x101eaf84]

[Andy Dustman]

Logged In: YES
user_id=71372

I'm afraid that doesn't help much. However, dbx probably has
a command that produces a stack backtrace. In gdb, this is
bt. A backtrace will be extremely helpful, but only if the
binary has not been stripped of it's symbol table. If nm
bin/python produces a lot of output, you should be ok.

It looks like the where command in dbx should produce a
backtrace, based on my google search.

[Richard Cook]

Logged In: YES
user_id=346175

Here's a trace from Linux, using python 1.5.2 (innermost first)
vivid1{rcook}:more trace.txt
Stack Trace
strcend, FP=bfffecd8
C mysql_read_default_options, FP=bfffed28
mysql_real_connect, FP=bffff0b8
C _mysql_connect, FP=bffff128
C call_builtin, FP=bffff158
C PyEval_CallObjectWithKeywords, FP=bffff188
C builtin_apply, FP=bffff1b8
C call_builtin, FP=bffff1e8
C PyEval_CallObjectWithKeywords, FP=bffff218
C eval_code2, FP=bffff2a8
C call_function, FP=bffff308
C PyEval_CallObjectWithKeywords, FP=bffff338
C PyInstance_New, FP=bffff368
C PyEval_CallObjectWithKeywords, FP=bffff398
C builtin_apply, FP=bffff3c8
C call_builtin, FP=bffff3f8
C PyEval_CallObjectWithKeywords, FP=bffff428
C eval_code2, FP=bffff4b8
C eval_code2, FP=bffff568
C PyEval_EvalCode, FP=bffff5a8
C run_node, FP=bffff5c8
C PyRun_InteractiveOne, FP=bffff638
C PyRun_InteractiveLoop, FP=bffff668
main, FP=bffff7c8
C __libc_start_main, FP=bffff808

Is that better? :-)
thanks

[Andy Dustman]

Logged In: YES
user_id=71372

You never did say what version of MySQL you were using. It
looks to me like it's crashing within the MySQL client library.

You can probably test this with a small C program:

include "mysql.h"

int main(void) {
MYSQL db, *r;
if (!(mysql_options(&db, MYSQL_READ_DEFAULT_FILE,
"/u1/rcook/.my.cnf'")) exit(1);
mysql_init(&db);
r = mysql_real_connect(&db, "host", "user", "password",
"db", 0, NULL, 0);
if (!r) exit(2);
exit(0);
}

If this also crashes, well, then it's a MySQL problem.

Usually in a traceback, you can get it to display function
arguments as well, which might also be useful.

[Richard Cook]

Logged In: YES
user_id=346175

I'm embarrassed to admit I don't understand what you're
saying exactly. I thought that MySQLdb just connects to the
remote server directly using sockets, without actually firing up
any MySQL client on its machine. Where would this mysql.h
file be located? On the machine from which I'm using python/
MySQLdb, there is no MySQL installation other than
MySQLdb. Should I look for mysql.h in my python library
directory somewhere? Thanks.
Are you asking what version the server is? The server I'm
connecting to is version 3.23.44.
>>> MySQLdb.version_info
(0, 9, 1, 'final', 1)
Sorry to be obtuse here...

[Andy Dustman]

Logged In: YES
user_id=71372

It does use sockets, but actually talking to the server is
what the client library does. This library is linked against
_mysql.so, which is the C portion of MySQLdb.

Hopefully you don't have to look for mysql.h. Since you
successfully compiled _mysql.so, you must already have it,
at least on the machine that MySQLdb was built on. setup.py
will list the include_path that the C compiler uses to find
it. But that's probably not important. You do have a recent
MySQL, so that's good, at least.

If possible, also try the most recent test verson of
MySQLdb. I hope to put the 0.9.2 release candidate out
today, but it should have less bugs, not more. There are
probably some memory-related fixes in there over 0.9.1;
check the changelog.

[Andy Dustman]

Logged In: YES
user_id=71372

This has been fixed in the current CVS tree.

[Andy Dustman]

Logged In: YES
user_id=71372

I never could reproduce this

[Richard Cook]

Logged In: YES
user_id=346175

I am waiting for the next release, I guess. In the meantime, I am parsing the .my.cnf file by hand in my program, the easiest fix for now.