Bug #35972 for DBD-SQLite: Segmentation fault by [ t/01logon ] on sun4-solaris-thread-multi-64int

Sat May 17 10:45:03 2008 ranjmis [...] gmail.com - Ticket created

Subject:

Segmentation fault by [ t/01logon ] on sun4-solaris-thread-multi-64int

Perl Version (having thread support) : 5.8.8 with DBI-1.54 and DBD-SQLite-1.14 Platform : osname=solaris, osvers=2.10, archname=sun4-solaris-thread-multi-64int There is core dump when t/01logon.t is run : -------------------------------------------- bash-3.00# perl t/01logon.t 1..5 # Running under perl version 5.008008 for solaris # Current time local: Sat May 17 18:45:08 2008 # Current time GMT: Sat May 17 13:15:08 2008 # Using Test.pm version 1.25 Segmentation Fault (core dumped) Core file analysis: ------------------ bash-3.00# mdb core Loading modules: [ libc.so.1 ld.so.1 ] Stack-Trace: ----------- Show quoted text

> $c

SQLite.so`XS_DBD__SQLite__db__login+0x350(14ebc0, 1d8588, 14ebc0, ffffffff, 2230b0, 2230c0) Perl_pp_entersub+0x684(22c710, 0, 14ebc0, 1d8588, 2230c0, 14ebc0) Perl_runops_standard+0x40(14ebc0, ffbff6f0, 0, fffffff8, 0, ffbff719) Perl_call_sv+0x260(0, ffbff6f0, 0, 0, 22c914, 14ebc0) DBI.so`XS_DBI_dispatch+0x233c(0, ff070194, 1587fc, 28be70, 284360, 21c320) Perl_pp_entersub+0x684(2f15d0, 0, 14ebc0, 2f15d0, 2230c4, 14ebc0) Perl_runops_standard+0x40(14ebc0, ff400000, ffc00000, 800000, 14ebc0, 0) S_run_body+0x194(14ebc0, 1, 14ebc0, 149400, ff3a2000, 2) perl_run+0x22c(14ebc0, 14ebc0, 2, ffbffcfc, 0, 14ebc0) main+0xbc(2, 14c808, ffbffcfc, 140c00, ff3a0100, ff3a0140) _start+0xb8(0, 0, 0, 0, 0, 0) Regs-Values: ----------- Show quoted text

> $r

%g0 = 0x00000000 %l0 = 0x00000000 %g1 = 0x0014e800 perl`PerlIO_fd_refcnt+0x1c70 %l1 = 0x00000004 %g2 = 0x00220ff8 %l2 = 0x002230b0 %g3 = 0x0000000a %l3 = 0x00000000 %g4 = 0x00000004 %l4 = 0x00000000 %g5 = 0x7ff00000 %l5 = 0x00000000 %g6 = 0x00000000 %l6 = 0x00000000 %g7 = 0xff3a2000 %l7 = 0xfefc79c8 %o0 = 0x0021b67c %i0 = 0x0014ebc0 %o1 = 0xfefb29b0 SQLite.so`.L3645 %i1 = 0x001d8588 %o2 = 0x00000005 %i2 = 0x0014ebc0 %o3 = 0x00000004 %i3 = 0xffffffff %o4 = 0x00000000 %i4 = 0x002230b0 %o5 = 0xff3a2100 %i5 = 0x002230c0 %o6 = 0xffbff420 %i6 = 0xffbff4d8 %o7 = 0xfef12e1c SQLite.so`XS_DBD__SQLite__db__login+0x33c %i7 = 0x0009c300 Perl_pp_entersub+0x684 %psr = 0xfe001002 impl=0xf ver=0xe icc=nzvc ec=0 ef=4096 pil=0 s=0 ps=0 et=0 cwp=0x2 %y = 0x00000000 %pc = 0xfef12e30 SQLite.so`XS_DBD__SQLite__db__login+0x350 %npc = 0xfef12e34 SQLite.so`XS_DBD__SQLite__db__login+0x354 %sp = 0xffbff420 %fp = 0xffbff4d8 %wim = 0x00000000 %tbr = 0x00000000 --------------------------------------------------------------------- First I thought it is something to with memory-alignment issue of sqlite on the sol-sparc system but it seems those things are already taken care of (saw guard bytes related code). As debuged so far it seems to die under XS_DBD__SQLite__db__login at D_imp_dbh. Although in the stack trace there are no further call refrences. ------------------------------------------------------- 215 XS(XS_DBD__SQLite__db__login) 216 { ... 235 D_imp_dbh(dbh); ------------------------------------------------------- Would appreciate if there is any clue on the possible fix.

Tue May 20 05:24:57 2008 ranjmis [...] gmail.com - Correspondence added

From:

ranjmis [...] gmail.com

Some more debug info : After prepocessing step (using cc on solaris) D_imp_dbh(dbh) expands to : --------------------------------------------------------- imp_dbh_t * imp_dbh = ( imp_dbh_t * ) ( ( ( * ( ( dbistate_t * * ) ( unsigned long ) ( & ( ( XPVIV * ) ( ( Perl_get_sv ( ( ( PerlInterpreter * ) pthread_getspecific ( ( * Perl_Gthr_key_ptr ( 0 ) ) ) ) , "DBI::_dbistate" , 0x05 ) ) ) -> sv_any ) -> xiv_iv ) ) ) -> getcom ( dbh ) ) ); --------------------------------------------------------- After breaking it down : SV *p1= Perl_get_sv ( ( ( PerlInterpreter * ) pthread_getspecific ( ( * Perl_Gthr_key_ptr ( 0 ) ) ) ) , "DBI::_dbistate" , 0x05 ); XPVIV *p2 = ( XPVIV * )(p1->sv_any); long iv = p2->xiv_iv; dbistate_t *p3 = *((dbistate_t**)(unsigned long)(&iv);) /* faults here */ /* dbistate_t *p3 = ((dbistate_t*)(unsigned long)(iv);) */ /* works till next function call but not sure whether this is right*/ void *p4 = (p3)->getcom(dbh); imp_dbh = ( imp_dbh_t * )p4; Although similar code works fine on Linux. Did a try with latest DBI-1.604 also but no luck. On Sat May 17 10:45:03 2008, ranjmis wrote: Show quoted text

> Perl Version (having thread support) : 5.8.8 with DBI-1.54 and > DBD-SQLite-1.14 > > Platform : > osname=solaris, osvers=2.10, archname=sun4-solaris-thread-multi-64int > > There is core dump when t/01logon.t is run : > -------------------------------------------- > bash-3.00# perl t/01logon.t > 1..5 > # Running under perl version 5.008008 for solaris > # Current time local: Sat May 17 18:45:08 2008 > # Current time GMT: Sat May 17 13:15:08 2008 > # Using Test.pm version 1.25 > Segmentation Fault (core dumped) > > Core file analysis: > ------------------ > bash-3.00# mdb core > Loading modules: [ libc.so.1 ld.so.1 ] > > Stack-Trace: > -----------

> > $c

> SQLite.so`XS_DBD__SQLite__db__login+0x350(14ebc0, 1d8588, 14ebc0, > ffffffff, 2230b0, 2230c0) > Perl_pp_entersub+0x684(22c710, 0, 14ebc0, 1d8588, 2230c0, 14ebc0) > Perl_runops_standard+0x40(14ebc0, ffbff6f0, 0, fffffff8, 0, ffbff719) > Perl_call_sv+0x260(0, ffbff6f0, 0, 0, 22c914, 14ebc0) > DBI.so`XS_DBI_dispatch+0x233c(0, ff070194, 1587fc, 28be70, 284360, 21c320) > Perl_pp_entersub+0x684(2f15d0, 0, 14ebc0, 2f15d0, 2230c4, 14ebc0) > Perl_runops_standard+0x40(14ebc0, ff400000, ffc00000, 800000, 14ebc0, 0) > S_run_body+0x194(14ebc0, 1, 14ebc0, 149400, ff3a2000, 2) > perl_run+0x22c(14ebc0, 14ebc0, 2, ffbffcfc, 0, 14ebc0) > main+0xbc(2, 14c808, ffbffcfc, 140c00, ff3a0100, ff3a0140) > _start+0xb8(0, 0, 0, 0, 0, 0) > > Regs-Values: > -----------

> > $r

> %g0 = 0x00000000 %l0 = 0x00000000 > %g1 = 0x0014e800 perl`PerlIO_fd_refcnt+0x1c70 %l1 = 0x00000004 > %g2 = 0x00220ff8 %l2 = 0x002230b0 > %g3 = 0x0000000a %l3 = 0x00000000 > %g4 = 0x00000004 %l4 = 0x00000000 > %g5 = 0x7ff00000 %l5 = 0x00000000 > %g6 = 0x00000000 %l6 = 0x00000000 > %g7 = 0xff3a2000 %l7 = 0xfefc79c8 > %o0 = 0x0021b67c %i0 = 0x0014ebc0 > %o1 = 0xfefb29b0 SQLite.so`.L3645 %i1 = 0x001d8588 > %o2 = 0x00000005 %i2 = 0x0014ebc0 > %o3 = 0x00000004 %i3 = 0xffffffff > %o4 = 0x00000000 %i4 = 0x002230b0 > %o5 = 0xff3a2100 %i5 = 0x002230c0 > %o6 = 0xffbff420 %i6 = 0xffbff4d8 > %o7 = 0xfef12e1c SQLite.so`XS_DBD__SQLite__db__login+0x33c %i7 = > 0x0009c300 Perl_pp_entersub+0x684 > > %psr = 0xfe001002 impl=0xf ver=0xe icc=nzvc > ec=0 ef=4096 pil=0 s=0 ps=0 et=0 cwp=0x2 > %y = 0x00000000 > %pc = 0xfef12e30 SQLite.so`XS_DBD__SQLite__db__login+0x350 > %npc = 0xfef12e34 SQLite.so`XS_DBD__SQLite__db__login+0x354 > %sp = 0xffbff420 > %fp = 0xffbff4d8 > > %wim = 0x00000000 > %tbr = 0x00000000 > > --------------------------------------------------------------------- > > First I thought it is something to with memory-alignment issue of sqlite > on the sol-sparc system but it seems those things are already taken care > of (saw guard bytes related code). > > As debuged so far it seems to die under XS_DBD__SQLite__db__login at > D_imp_dbh. Although in the stack trace there are no further call

refrences. Show quoted text

> > ------------------------------------------------------- > 215 XS(XS_DBD__SQLite__db__login) > 216 { > ... > 235 D_imp_dbh(dbh); > ------------------------------------------------------- > > Would appreciate if there is any clue on the possible fix.

Thu May 22 17:32:21 2008 ranjmis [...] gmail.com - Correspondence added

From:

ranjmis [...] gmail.com

Guys, Found that problem was in DBIS macro definition from DBI where it does INT2PTR by doing & , ** and * on iv. This is a problem in case integer and pointer bytes differ and hence the error on sparc. (Thanks to PVANDRY also for wonderful explanation at http://rt.cpan.org/Public/Bug/Display.html?id=32309) Fix: In SQLiteXS.h override DBIS and also define DBISV : #undef DBIS #define DBIS (INT2PTR(dbistate_t*, SvIVX(DBISTATE_ADDRSV))) #define DBISV SvIVX(DBISTATE_ADDRSV) In dbdimp.c : void sqlite_init(dbistate_t *dbistate) { dTHR; DBISV = dbistate; /*Earlier DBIS = dbistate*/ } Patch for the same: --------------------------------------- diff -u DBD-SQLite-1.14/SQLiteXS.h DBD-SQLite-1.14.fix/SQLiteXS.h --- DBD-SQLite-1.14/SQLiteXS.h 2008-05-22 13:42:48.000000000 +0530 +++ DBD-SQLite-1.14.fix/SQLiteXS.h 2008-05-22 13:42:57.000000000 +0530 @@ -13,4 +13,8 @@ #include "sqlite3.h" #include "ppport.h" +#undef DBIS +#define DBIS (INT2PTR(dbistate_t*, SvIVX(DBISTATE_ADDRSV))) +#define DBISV SvIVX(DBISTATE_ADDRSV) + #endif diff -u DBD-SQLite-1.14/dbdimp.c DBD-SQLite-1.14.fix/dbdimp.c --- DBD-SQLite-1.14/dbdimp.c 2008-05-22 13:44:10.000000000 +0530 +++ DBD-SQLite-1.14.fix/dbdimp.c 2008-05-22 13:42:56.000000000 +0530 @@ -29,7 +29,7 @@ sqlite_init(dbistate_t *dbistate) { dTHR; - DBIS = dbistate; + DBISV = dbistate; } static void --------------------------------------- On Tue May 20 05:24:57 2008, ranjmis wrote: Show quoted text

> Some more debug info : > > After prepocessing step (using cc on solaris) D_imp_dbh(dbh) expands to : > --------------------------------------------------------- > imp_dbh_t * imp_dbh = ( imp_dbh_t * ) ( ( ( * ( ( dbistate_t * * ) ( > unsigned long ) ( & ( ( XPVIV * ) ( ( Perl_get_sv ( > ( ( PerlInterpreter * ) pthread_getspecific ( ( * Perl_Gthr_key_ptr ( 0 > ) ) ) ) , "DBI::_dbistate" , 0x05 ) ) ) -> sv_any ) > -> xiv_iv ) ) ) -> getcom ( dbh ) ) ); > --------------------------------------------------------- > > After breaking it down : > > SV *p1= Perl_get_sv ( ( ( PerlInterpreter * ) pthread_getspecific ( ( * > Perl_Gthr_key_ptr ( 0 ) ) ) ) , "DBI::_dbistate" , 0x05 ); > XPVIV *p2 = ( XPVIV * )(p1->sv_any); > long iv = p2->xiv_iv; > dbistate_t *p3 = *((dbistate_t**)(unsigned long)(&iv);) /* faults here */ > /* dbistate_t *p3 = ((dbistate_t*)(unsigned long)(iv);) */ /* works till > next function call but not sure whether this is right*/ > void *p4 = (p3)->getcom(dbh); > imp_dbh = ( imp_dbh_t * )p4; > > Although similar code works fine on Linux. > Did a try with latest DBI-1.604 also but no luck. > > On Sat May 17 10:45:03 2008, ranjmis wrote:

> > Perl Version (having thread support) : 5.8.8 with DBI-1.54 and > > DBD-SQLite-1.14 > > > > Platform : > > osname=solaris, osvers=2.10, archname=sun4-solaris-thread-multi-64int > > > > There is core dump when t/01logon.t is run : > > -------------------------------------------- > > bash-3.00# perl t/01logon.t > > 1..5 > > # Running under perl version 5.008008 for solaris > > # Current time local: Sat May 17 18:45:08 2008 > > # Current time GMT: Sat May 17 13:15:08 2008 > > # Using Test.pm version 1.25 > > Segmentation Fault (core dumped) > > > > Core file analysis: > > ------------------ > > bash-3.00# mdb core > > Loading modules: [ libc.so.1 ld.so.1 ] > > > > Stack-Trace: > > -----------

> > > $c

> > SQLite.so`XS_DBD__SQLite__db__login+0x350(14ebc0, 1d8588, 14ebc0, > > ffffffff, 2230b0, 2230c0) > > Perl_pp_entersub+0x684(22c710, 0, 14ebc0, 1d8588, 2230c0, 14ebc0) > > Perl_runops_standard+0x40(14ebc0, ffbff6f0, 0, fffffff8, 0, ffbff719) > > Perl_call_sv+0x260(0, ffbff6f0, 0, 0, 22c914, 14ebc0) > > DBI.so`XS_DBI_dispatch+0x233c(0, ff070194, 1587fc, 28be70, 284360,

21c320) Show quoted text

> > Perl_pp_entersub+0x684(2f15d0, 0, 14ebc0, 2f15d0, 2230c4, 14ebc0) > > Perl_runops_standard+0x40(14ebc0, ff400000, ffc00000, 800000, 14ebc0, 0) > > S_run_body+0x194(14ebc0, 1, 14ebc0, 149400, ff3a2000, 2) > > perl_run+0x22c(14ebc0, 14ebc0, 2, ffbffcfc, 0, 14ebc0) > > main+0xbc(2, 14c808, ffbffcfc, 140c00, ff3a0100, ff3a0140) > > _start+0xb8(0, 0, 0, 0, 0, 0) > > > > Regs-Values: > > -----------

> > > $r

> > %g0 = 0x00000000 %l0 = 0x00000000 > > %g1 = 0x0014e800 perl`PerlIO_fd_refcnt+0x1c70 %l1 = 0x00000004 > > %g2 = 0x00220ff8 %l2 = 0x002230b0 > > %g3 = 0x0000000a %l3 = 0x00000000 > > %g4 = 0x00000004 %l4 = 0x00000000 > > %g5 = 0x7ff00000 %l5 = 0x00000000 > > %g6 = 0x00000000 %l6 = 0x00000000 > > %g7 = 0xff3a2000 %l7 = 0xfefc79c8 > > %o0 = 0x0021b67c %i0 = 0x0014ebc0 > > %o1 = 0xfefb29b0 SQLite.so`.L3645 %i1 = 0x001d8588 > > %o2 = 0x00000005 %i2 = 0x0014ebc0 > > %o3 = 0x00000004 %i3 = 0xffffffff > > %o4 = 0x00000000 %i4 = 0x002230b0 > > %o5 = 0xff3a2100 %i5 = 0x002230c0 > > %o6 = 0xffbff420 %i6 = 0xffbff4d8 > > %o7 = 0xfef12e1c SQLite.so`XS_DBD__SQLite__db__login+0x33c %i7 = > > 0x0009c300 Perl_pp_entersub+0x684 > > > > %psr = 0xfe001002 impl=0xf ver=0xe icc=nzvc > > ec=0 ef=4096 pil=0 s=0 ps=0 et=0 cwp=0x2 > > %y = 0x00000000 > > %pc = 0xfef12e30 SQLite.so`XS_DBD__SQLite__db__login+0x350 > > %npc = 0xfef12e34 SQLite.so`XS_DBD__SQLite__db__login+0x354 > > %sp = 0xffbff420 > > %fp = 0xffbff4d8 > > > > %wim = 0x00000000 > > %tbr = 0x00000000 > > > > --------------------------------------------------------------------- > > > > First I thought it is something to with memory-alignment issue of sqlite > > on the sol-sparc system but it seems those things are already taken care > > of (saw guard bytes related code). > > > > As debuged so far it seems to die under XS_DBD__SQLite__db__login at > > D_imp_dbh. Although in the stack trace there are no further call

> refrences.

> > > > ------------------------------------------------------- > > 215 XS(XS_DBD__SQLite__db__login) > > 216 { > > ... > > 235 D_imp_dbh(dbh); > > ------------------------------------------------------- > > > > Would appreciate if there is any clue on the possible fix.

Thu Apr 09 05:50:08 2009 adamk [...] cpan.org - Correspondence added

DBIS turns out to be deprecated in the DBIXS.h and so we're moving away from it to it's replacement. Can you take another look with the latest trunk and see if the replacement for DBIS avoids this problem? If not, we may need to look at pushing a patch upstream to DBI.

Thu Apr 09 05:50:10 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Apr 23 06:46:00 2009 adamk [...] cpan.org - Correspondence added

All the solaris CPAN Testers runs that I can see pass now. Resolving pending the original requester reporting on fresh testing.

Thu Apr 23 06:46:03 2009 adamk [...] cpan.org - Status changed from 'open' to 'resolved'