[DBD-SQLite] load_extension("perlvtab.so")

[Salvador Fandino]

----- Original Message ----
> From: Tim Bunce <Tim.Bunce at pobox.com>
> To: Brian Duggan <bduggan at matatu.org>
> Cc: dbd-sqlite at lists.scsys.co.uk; sfandino at yahoo.com
> Sent: Fri, October 30, 2009 12:15:19 AM
> Subject: Re: [DBD-SQLite] load_extension("perlvtab.so")
> 
> On Thu, Oct 29, 2009 at 11:35:24AM -0400, Brian Duggan wrote:
> > $ gdb -c core perl test.pl
> > [..]
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x00f90029 in dbih_clearcom (imp_xxh=0x8c29950) at DBI.xs:1432
> > 1432        int debug = DBIS_TRACE_LEVEL;
> 
> #define DBIS_TRACE_LEVEL  (DBIS->debug & DBIc_TRACE_LEVEL_MASK)
> 
> > (gdb) where
> > #0  0x00f90029 in dbih_clearcom (imp_xxh=0x8c29950) at DBI.xs:1432
> > #1  0x00f8295d in XS_DBD___mem__common_DESTROY (my_perl=0x8c02008, 
> cv=0x8c68c08) at DBI.xs:5135
> ...
> > #15 0x080b8b79 in Perl_sv_clean_objs (my_perl=0x8c02008) at sv.c:495
> > #16 0x080af3c7 in perl_destruct (my_perl=0x8c02008) at perl.c:799
> 
> Happening during the early object destruction phase of global destruction.
> 
> >   Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
> >                         PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS
> 
> Compiled with MULTIPLICITY and USE_ITHREADS, so DBIS expands to
> (*(INT2PTR(dbistate_t**, &SvIVX(DBISTATE_ADDRSV)))). Long story.
> 
> I can't think why accessing DBIS->debug would be a problem during the
> early object destruction phase of global destruction.

SQLite::VirtualTable is not a regular perl module. It was designed to be called not from DBD::SQLite but from the sqlite shell, and so, it instantiates its own Perl interpreter that gets embedded into the sqlite3 process.

Calling it from DBD::SQLite seems to work under non threaded perls. But with threaded versions it SIGSEGVs, that's probably due to both interpreters using the same key for thread local storage.

IMO the only possible solution is to rewrite the module to use the preexistent perl interpreter when called from DBD::SQLite, but it is not something easy to do, specially if it has to remain usable from other non perl sqlite clients.

Also, currently DBD::SQLite doesn't fully expose the subset of sqlite3 C API required by SQLite::VirtualTable. I have been playing with DynaLoader::dl_find_symbol_anywhere() to get direct access to it but this approach doesn't seem to be portable... probably the easiest way would be to just integrate SQLite::VirtualTable into DBD::SQLite and maintain a different version for usage outside of perl.

Any thoughts?

Cheers,

- Salva