On Fri, Nov 05, 2004 at 02:48:59PM +0000, Tim Bunce wrote: > 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]
Anyone got an update to this? Tim.
