On Fri, May 30, 2003 at 03:41:47PM +0200, Steffen Goeldner wrote: > I have a core dump in DBD-Oracle-1.14/test.pl. > To get a trace, I added > > DBI->trace(9); > > at line 131 (before exit). > Attached is the trace file. > > BTW: The script does not dump if I set DBI_TRACE=1. > > DBI 1.37-ithread dispatch trace level set to 9 > -- DBI::END
The DBI::END marker means perl is cleaning up, starting with 'cleanly' calling END blocks. > ! -> DESTROY for DBD::Oracle::dr (DBI::dr=HASH(0x17f63f8)~INNER) thr#015EF12C The exclamation mark at the start of the trace lines (a new feature in DBI 1.37) shows that perl is non in 'dirty' global destruction mode. The order in which objects are destroyed is undefined during global destruction. You happen to have hit the worst case: > DESTROY (dbih_clearcom) (drh 0x1891928 0x182a4dc, com 0x182a784, imp > DBD::Oracle::dr): First the drh, then the dbh: > ! -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x17223e4)~INNER) thr#015EF12C > OCIHandleFree(020E5DB0,OCI_HTYPE_SESSION)=SUCCESS > OCIHandleFree(020C8F58,OCI_HTYPE_SERVER)=SUCCESS > OCIHandleFree(020C8EB4,OCI_HTYPE_SVCCTX)=SUCCESS > OCIHandleFree(020C914C,OCI_HTYPE_ERROR)=SUCCESS > ! <- DESTROY= undef during global destruction > DESTROY (dbih_clearcom) (dbh 0x1722390 0x1ae9174, com 0x1ae8578, imp > DBD::Oracle::db): > FLAGS 0xa321: COMSET CompatMode PrintError HandleError ShowErrorStatement > AutoCommit > PARENT undef > KIDS 1 (0 Active) > IMP_DATA undef > dbih_clearcom 0x1722390 (com 0x1ae8578, type 2) done. then the sth: > ! -> DESTROY for DBD::Oracle::st (DBI::st=HASH(0x188b7a4)~INNER) thr#015EF12C but cleaning up an sth that belongs to a dbh that's been destroyed is not a way to happiness... I'll see if I can improve the behaviour in this case. Meanwhile try to make sure you're sth's are (manually) destroyed before you exit. Tim.
