[Python-Dev] Build problems with sqlite on OSX

[Darrin Thompson]

On 5/29/07, "Martin v. Löwis" <martin at v.loewis.de> 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
<sqlite3InitCallback>, 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
88                azVals = &azCols[nCol];
89                for(i=0; i<nCol; i++){
90                  azVals[i] = (char *)sqlite3_column_text(pStmt, i);
91                }
92              }
93              if( xCallback(pArg, nCol, azVals, azCols) ){ -- here --
94                rc = SQLITE_ABORT;
95                goto exec_out;
96              }
97            }

I don't have source info on frame 2 and above, which is really odd, as
sqlite is statically linked to _sqlite3.so.

>From 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