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. _______________________________________________ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite