On Mon, Nov 01, 2004 at 12:31:38PM -0800, David Oswald wrote: > I wanted to draw your attention to the following discussion regarding a Perl > segfault that exists across multiple platforms, and across multiple > databases: > > http://www.perlmonks.org/index.pl?node_id=404161
Max Maischein has kindly sent me a stack trace for this problem using SQLite: > #0 0x402a1f7a in vdbeUnbind (p=0x0, i=1) at vdbeapi.c:425 > #1 0x402a2041 in bindText (pStmt=0x0, i=1, zData=0x825bbe8, > nData=5,xDel=0xffffffff, encoding=1) at vdbeapi.c:455 > #2 0x402a22ad in sqlite3_bind_text (pStmt=0x0, i=1, zData=0x825bbe8 "shine", > nData=5, xDel=0xffffffff) at vdbeapi.c:514 > #3 0x40271a19 in sqlite_st_execute (sth=0x8308cdc, imp_sth=0x86df720) at > dbdimp.c:355 > #4 0x40258dac in XS_DBD__SQLite__db_selectrow_arrayref (my_perl=0x813ee48, > cv=0x86a4758) at SQLite.xsi:171 The segfault is from within SQLite. The sqlite_st_execute function is calling sqlite3_bind_text with a null pointer for imp_sth->stmt. Sure seems like a DBD::SQLite problem, or perhaps SQLite itself. Looking at the code one possible explanation would be if the sqlite3_prepare(..., &(imp_sth->stmt), ...) call within sqlite_st_execute() is returning SQLITE_OK but setting imp_sth->stmt to null. [CC'd to Matt Sergeant for comment] Tim.
