[Python-Dev] Build problems with sqlite on OSX
First of all 1000 apologies if this is the wrong list. Please redirect me if necessary. I'm attempting to build python 2.5.1 fat binaries on OSX and statically link to a newer sqlite than what ships with OSX. (3.3.17). I'm getting "Bus Error" early when I run my app. If I turn on a lot of malloc debugging options and run under gdb I get this trace: (gdb) info threads * 1 process 18968 local thread 0x1003 0x900e41d1 in strtol_l () (gdb) bt #0 0x900e41d1 in strtol_l () #1 0x900160a5 in atoi () #2 0x9406fd80 in sqlite3InitCallback () #3 0x0381faf2 in sqlite3_exec (db=0x338d080, zSql=0x331f1e0 "SELECT name, rootpage, sql FROM 'main'.sqlite_master WHERE tbl_name='sqlite_sequence'", xCallback=0x9406fd00 , pArg=0xbfffde14, pzErrMsg=0x0) at ./src/legacy.c:93 #4 0x0384c769 in sqlite3VdbeExec (p=0x1945200) at ./src/vdbe.c:4090 #5 0x03816686 in sqlite3Step (p=0x1945200) at ./src/vdbeapi.c:236 #6 0x03816817 in sqlite3_step (pStmt=0x1945200) at ./src/vdbeapi.c:289 #7 0x0380b9aa in _sqlite_step_with_busyhandler (statement=0x1945200, connection=0x32a77a0) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/util.c:33 #8 0x0380850d in cursor_executescript (self=0x32bd4d0, args=0x32a2d10) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/cursor.c:788 #9 0x0020e6fc in PyObject_Call (func=0x329ecd8, arg=0x32a2d10, kw=0x0) at Objects/abstract.c:1860 #10 0x00292a36 in PyEval_CallObjectWithKeywords (func=0x329ecd8, arg=0x32a2d10, kw=0x0) at Python/ceval.c:3433 #11 0x0020e6cd in PyObject_CallObject (o=0x329ecd8, a=0x32a2d10) at Objects/abstract.c:1851 #12 0x03806e1c in connection_executescript (self=0x32a77a0, args=0x32a2d10, kwargs=0x0) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/connection.c:1001 #13 0x002998ae in PyEval_EvalFrameEx (f=0x338c250, throwflag=0) at Python/ceval.c:3564 Can someone advise as to the correct configure arguments for sqlite or something else I might be missing? Thanks in advance. -- Darrin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build problems with sqlite on OSX
On 5/29/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > What happens when you use the binary installer at python.org? This is > build with a newer version of sqlite as well (because the installer > supports OSX 10.3). > Hmmm. I hadn't thought of checking the sqlite version in there. I did use the binary installer once but had "other problems" which I'm now suspecting were my misuse of Qt's pyrcc. > The script that builds the binary installer is in Mac/BuildScript. > Sweet! I'll look into this. -- Darrin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build problems with sqlite on OSX
On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The question for python-dev is "how can I debug that further, and where
> should I submit a patch" :-)
>
I have no problem with that. :-)
> > (gdb) info threads
> > * 1 process 18968 local thread 0x1003 0x900e41d1 in strtol_l ()
> > (gdb) bt
> > #0 0x900e41d1 in strtol_l ()
> > #1 0x900160a5 in atoi ()
> > #2 0x9406fd80 in sqlite3InitCallback ()
>
> Can you figure out what parameter is being passed to atoi() here?
> Go up (u) a few stack frames, list (l) the source, and print (p)
> the variables being passed to atoi().
Well, duh!
#3 0x0395faca in sqlite3_exec (db=0x338d160, zSql=0x338faf0 "SELECT
name, rootpage, sql FROM 'main'.sqlite_master WHERE
tbl_name='sqlite_sequence'", xCallback=0x9406fd00
, pArg=0xbfffde14, pzErrMsg=0x0) at
./src/legacy.c:93
#4 0x0398c741 in sqlite3VdbeExec (p=0x1943e00) at ./src/vdbe.c:4090
#5 0x0395665e in sqlite3Step (p=0x1943e00) at ./src/vdbeapi.c:236
(gdb) l
88azVals = &azCols[nCol];
89for(i=0; iFrom looking at the source code I know that what is being passed to
atoi is supposed to be a root page number.
int sqlite3InitCallback(void *pInit, int argc, char **argv, char **azColName){
Specifically, argv[1] is what goes to atoi, and is documented to be a
root page number. All kinds of possibilities suggest themselves.
> I'm puzzled that it doesn't
> display source code information - so one possible cause is that
> you pick up the wrong sqlite3InitCallback (i.e. the one that
> came with OSX, instead of the one you built yourself).
I'm confident it isn't picking up the wrong lib, based on otool -L:
$ otool -L
/opt/so/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/lib-dynload/_sqlite3.so
/opt/so/Library/Frameworks/Python.framework/Versions/Current/lib/python2.5/lib-dynload/_sqlite3.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)
On Linux I might also poke around in /proc to see what files were
mapped into memory, but I'm not sure how to do that on OSX yet.
--
Darrin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build problems with sqlite on OSX
On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > p &sqlite3InitCallback > (gdb) p $sqlite3InitCallback $1 = void g. > Try "info shared" in gdb. Not sure whether that works on OSX, > though. > Worked beautifully! The smoking gun: something is hauling in the system provided sqlite3 in addition to my static one. (Weren't you just saying that?) I'm going to investigate that further unless you tell me I'm an idiot. I suspect it's the official Qt binaries from Trolltech doing it indirectly. Plus that's the only way I can rationalize some sqlite functions having source available and some acting like they've been stripped. -- Darrin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
