#34 connect() crash with read_default_file

MySQLdb-0.9.2
closed
Andy Dustman
MySQLdb (285)
5
2012-09-19
2002-05-24
Richard Cook
No

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.

Discussion

1 2 > >> (Page 1 of 2)
  • Andy Dustman
    Andy Dustman
    2002-05-31

    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
    Richard Cook
    2002-05-31

    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
    Andy Dustman
    2002-05-31

    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
    Richard Cook
    2002-05-31

    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
    Andy Dustman
    2002-06-03

    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
    Richard Cook
    2002-06-03

    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
    Andy Dustman
    2002-06-04

    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
    Richard Cook
    2002-06-04

    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
    Andy Dustman
    2002-06-04

    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
    Andy Dustman
    2002-07-01

    Logged In: YES
    user_id=71372

    This has been fixed in the current CVS tree.

     
1 2 > >> (Page 1 of 2)