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

[Tim Bunce]

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.

What does "print *imp_xxh->com.std.dbistate" show in gdb?
(I've not tested that so it might not be right.)

This may help, or it may just shift or hide the underlying problem:

--- DBI.xs  (revision 13337)
+++ DBI.xs  (working copy)
@@ -1436,7 +1436,7 @@
     dPERINTERP;
     dTHR;
     int dump = FALSE;
-    int debug = DBIS_TRACE_LEVEL;
+    int debug = DBIc_TRACE_LEVEL(imp_xxh);
     int auto_dump = (debug >= 6);
     imp_xxh_t * const parent_xxh = DBIc_PARENT_COM(imp_xxh);
     /* Note that we're very much on our own here. DBIc_MY_H(imp_xxh) almost   */


Tim.