Skip Menu |

This queue is for tickets about the DB_File CPAN distribution.

Report information
The Basics
Id: 3211
Status: open
Priority: 0/
Queue: DB_File

People
Owner: pmqs [...] cpan.org
Requestors: softadm [...] wias-berlin.de
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: core dump in db-hash.t under OSF1
hallo, there ist a problem with all releases of DB_File i tried (perl5.003 ... perl-5.6, and also DB_File-1.806) in connection with /usr/lib/libdb.so which is shipped with OSF1 V5.1 (True64 Unix). ok(22, $X = tie(%h,'DB_File',$Dfile, O_RDWR, 0640) ); fails with core dump. in version 1.75 the c-source looks like line 1672 "DB_File.xs" CurrentDB = db ; #line 1756 "DB_File.c" RETVAL = db_DELETE(db, key, flags); XSprePUSH; PUSHi((IV)RETVAL); } XSRETURN(1); } db_DELETE which expands to some_pointer->del crashes. i think, this is a problem of the "build in" libdb. with the aktuell version 4.1 of BerkeleyDB the problem disapears. ingo bremer
[guest - Mon Aug 11 10:04:57 2003]: Show quoted text
> hallo, > > there ist a problem with all releases of DB_File i tried > (perl5.003 ... perl-5.6, and also DB_File-1.806) > in connection with /usr/lib/libdb.so which is shipped with OSF1 V5.1 > (True64 Unix). > > ok(22, $X = tie(%h,'DB_File',$Dfile, O_RDWR, 0640) ); > > fails with core dump. > > in version 1.75 the c-source looks like > > line 1672 "DB_File.xs" > CurrentDB = db ; > #line 1756 "DB_File.c" > > RETVAL = db_DELETE(db, key, flags); > XSprePUSH; PUSHi((IV)RETVAL); > } > XSRETURN(1); > } > > db_DELETE which expands to some_pointer->del crashes. > > i think, this is a problem of the "build in" libdb. with the aktuell > version 4.1 of BerkeleyDB the problem disapears. > > ingo bremer > >
Hi Ingo, only just spotted this error report, because the DB_File queue was accidentally not assigned to me. Good to hear you sorted the problem yourself, but I'd like to add something in the DB_File README about this if I can. If you have the time, and still have the old version of Berkeley DB available, can you send me a complete log of the complete build process and the make test step please? Also, what is the aktuell version 4.1 of BerkeleyDB? cheers Paul
From: htoug [...] cpan.org
[PMQS - Mon Oct 20 09:10:55 2003]: Show quoted text
> [guest - Mon Aug 11 10:04:57 2003]: >
> > hallo, > > > > there ist a problem with all releases of DB_File i tried > > (perl5.003 ... perl-5.6, and also DB_File-1.806) > > in connection with /usr/lib/libdb.so which is shipped with OSF1 V5.1 > > (True64 Unix). > > > > ok(22, $X = tie(%h,'DB_File',$Dfile, O_RDWR, 0640) ); > > > > fails with core dump. > > > > in version 1.75 the c-source looks like > > > > line 1672 "DB_File.xs" > > CurrentDB = db ; > > #line 1756 "DB_File.c" > > > > RETVAL = db_DELETE(db, key, flags); > > XSprePUSH; PUSHi((IV)RETVAL); > > } > > XSRETURN(1); > > }
I have just 'banged head on' into this problem. Digging a bit deeper into the code, I discover that the db_DELETE call is translated into: ((db->dbp)->del)(db->dbp, TXN &key, 0) Looking in the documentation for dbopen on Tru64 (OSF/1) v5.1B I see: ... typedef struct { DBTYPE type; int (*close)(const DB *db); int (*del)(const DB *db, const DBT *key, u_int option); int (*fd)(const DB *db); int (*get)(const DB *db, DBT *key, DBT *data, u_int option); int (*put)(const DB *db, DBT *key, const DBT *data, u_int option); int (*sync)(const DB *db, u_int option); int (*seq)(const DB *db, DBT *key, DBT *data, u_int option); } DB; ... del A pointer to a routine to remove key/data pairs from the database. The parameter option can be set to the following value: R_CURSOR Delete the record referenced by the cursor. The cursor must have previously been initialized. The del routines return -1 on error (setting errno), 0 on suc- cess, and 1 if the specified key was not in the file. Checking for the value of R_CURSOR in /usr/include/db.h I find: #define R_CURSOR 1 /* del, put, seq */ My guess is that the builtin library SEGV's given a value of 0 for the option parameter - which could be construed as a bug on the part of the db-lib (I'll report that to Digi^WComp^WHP asap). Somehow the build process will need to avoid the builtin DB-library on Tru64 and request another one. I'll be happy to try to help avoiding this nasty bug if I can. A log of a build (using Perl 5.6.1) is here: <ht000@tortuga:/home/ht000/.cpan/build/DB_File-1.810:!>$ or$ perl Makefile.PL Parsing config.in... Looks Good. Checking if your kit is complete... Looks good Writing Makefile for DB_File <ht000@tortuga:/home/ht000/.cpan/build/DB_File-1.810:!>$ or$ make cp DB_File.pm blib/lib/DB_File.pm AutoSplitting blib/lib/DB_File.pm (blib/lib/auto/DB_File) cc -c -I/usr/local/BerkeleyDB/include -std -fprm d -ieee -D_INTRINSICS -I/usr/l ocal/include -DLANGUAGE_C -O4 -DVERSION=\"1.810\" -DXS_VERSION=\"1.810\" "-I/ usr/local/lib/perl5/5.6.1/alpha-dec_osf/CORE" -D_NOT_CORE -DmDB_Prefix_t=size_ t -DmDB_Hash_t=u_int32_t version.c /usr/local/bin/perl /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp -noprototypes -ty pemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap -typemap typemap DB_File.xs > DB_File.xsc && mv DB_File.xsc DB_File.c cc -c -I/usr/local/BerkeleyDB/include -std -fprm d -ieee -D_INTRINSICS -I/usr/l ocal/include -DLANGUAGE_C -O4 -DVERSION=\"1.810\" -DXS_VERSION=\"1.810\" "-I/ usr/local/lib/perl5/5.6.1/alpha-dec_osf/CORE" -D_NOT_CORE -DmDB_Prefix_t=size_ t -DmDB_Hash_t=u_int32_t DB_File.c Running Mkbootstrap for DB_File () chmod 644 DB_File.bs ar cr tmp.a version.o DB_File.o : tmp.a rm -f blib/arch/auto/DB_File/DB_File.so LD_RUN_PATH="/usr/shlib" ld -shared -expect_unresolved "*" -O4 -msym -std -s -L /usr/local/lib -all tmp.a -none -o blib/arch/auto/DB_File/DB_File.so -ldb chmod 755 blib/arch/auto/DB_File/DB_File.so cp DB_File.bs blib/arch/auto/DB_File/DB_File.bs chmod 644 blib/arch/auto/DB_File/DB_File.bs Manifying blib/man3/DB_File.3 <ht000@tortuga:/home/ht000/.cpan/build/DB_File-1.810:!>$ or$ make test Running Mkbootstrap for DB_File () chmod 644 DB_File.bs ar cr tmp.a version.o DB_File.o : tmp.a rm -f blib/arch/auto/DB_File/DB_File.so LD_RUN_PATH="/usr/shlib" ld -shared -expect_unresolved "*" -O4 -msym -std -s -L /usr/local/lib -all tmp.a -none -o blib/arch/auto/DB_File/DB_File.so -ldb chmod 755 blib/arch/auto/DB_File/DB_File.so cp DB_File.bs blib/arch/auto/DB_File/DB_File.bs chmod 644 blib/arch/auto/DB_File/DB_File.bs PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" "test_harne ss(0, 'blib/lib', 'blib/arch')" t/*.t t/db-btree....ok t/db-hash.....dubious Test returned status -1 (wstat 139, 0x8b) Executing /usr/bin/dbx "/usr/local/bin/perl" "core" (where)... dbx version 5.1 Type 'help' for help. Core file created by program "perl" signal Segmentation fault at >*[__free_ovflpage, 0x3ff810cb040] ldl t 2, 24(a1) Show quoted text
> 0 __free_ovflpage(0x3ff810c63dc, 0x2, 0x3ff810c6b34, 0x140205408,
0x1401fec40 ) [0x3ff810cb040] 1 __big_delete(0x3ff810c429c, 0x14021a80a, 0x1, 0x4, 0x1401fec40) [0x3ff810c6 b50] 2 (unknown)() [0x3ff810c4298] /usr/bin/dbx: fatal error: hit EOF on standard input file t/db-recno.... make: *** [test_dynamic] Interrupt
From: "Paul Marquess" <paul.marquess [...] ntlworld.com>
To: <bug-DB_File [...] rt.cpan.org>, <"undisclosed-recipients:" [...] pallas.eruditorum.org>
Subject: RE: [cpan #3211] core dump in db-hash.t under OSF1
Date: Thu, 18 Nov 2004 09:38:46 -0000
RT-Send-Cc:
Hi, I assume OSF ships with Berkeley DB 1.85 (or 1.86). Without more detailed evidence, I'm not so sure about your guess that passing a 0 to the delete method is causing this problem - the btree test harness worked fine and it does all the same things the hash test suite does. If you run the test suite in verbose mode we can see which test it is tripping over. make test TEST_VERBOSE=1 cheers Paul Show quoted text
> -----Original Message----- > From: Henrik_Tougaard via RT [mailto:bug-DB_File@rt.cpan.org] > Sent: 17 November 2004 14:00 > To: undisclosed-recipients: > Subject: [cpan #3211] core dump in db-hash.t under OSF1 > > > This message about DB_File was sent to you by HTOUG <HTOUG@cpan.org> via > rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=3211 > > > [PMQS - Mon Oct 20 09:10:55 2003]: >
> > [guest - Mon Aug 11 10:04:57 2003]: > >
> > > hallo, > > > > > > there ist a problem with all releases of DB_File i tried > > > (perl5.003 ... perl-5.6, and also DB_File-1.806) > > > in connection with /usr/lib/libdb.so which is shipped with OSF1 V5.1 > > > (True64 Unix). > > > > > > ok(22, $X = tie(%h,'DB_File',$Dfile, O_RDWR, 0640) ); > > > > > > fails with core dump. > > > > > > in version 1.75 the c-source looks like > > > > > > line 1672 "DB_File.xs" > > > CurrentDB = db ; > > > #line 1756 "DB_File.c" > > > > > > RETVAL = db_DELETE(db, key, flags); > > > XSprePUSH; PUSHi((IV)RETVAL); > > > } > > > XSRETURN(1); > > > }
> > I have just 'banged head on' into this problem. Digging a bit deeper > into the code, I discover that the db_DELETE call is translated into: > ((db->dbp)->del)(db->dbp, TXN &key, 0) > > Looking in the documentation for dbopen on Tru64 (OSF/1) v5.1B I see: > ... > typedef struct { > DBTYPE type; > int (*close)(const DB *db); > int (*del)(const DB *db, const DBT *key, u_int option); > int (*fd)(const DB *db); > int (*get)(const DB *db, DBT *key, DBT *data, u_int option); > int (*put)(const DB *db, DBT *key, const DBT *data, u_int > option); > int (*sync)(const DB *db, u_int option); > int (*seq)(const DB *db, DBT *key, DBT *data, u_int option); > } DB; > ... > del A pointer to a routine to remove key/data pairs from the > database. > > The parameter option can be set to the following value: > > R_CURSOR > Delete the record referenced by the cursor. The cursor > must > have previously been initialized. > > The del routines return -1 on error (setting errno), 0 > on suc- > cess, and 1 if the specified key was not in the file. > > Checking for the value of R_CURSOR in /usr/include/db.h I find: > #define R_CURSOR 1 /* del, put, seq */ > > My guess is that the builtin library SEGV's given a value of 0 for the > option parameter - which could be construed as a bug on the part of the > db-lib (I'll report that to Digi^WComp^WHP asap). > > Somehow the build process will need to avoid the builtin DB-library on > Tru64 and request another one. > > I'll be happy to try to help avoiding this nasty bug if I can. > > > A log of a build (using Perl 5.6.1) is here: > > <ht000@tortuga:/home/ht000/.cpan/build/DB_File-1.810:!>$ or$ perl > Makefile.PL > Parsing config.in... > Looks Good. > Checking if your kit is complete... > Looks good > Writing Makefile for DB_File > <ht000@tortuga:/home/ht000/.cpan/build/DB_File-1.810:!>$ or$ make > cp DB_File.pm blib/lib/DB_File.pm > AutoSplitting blib/lib/DB_File.pm (blib/lib/auto/DB_File) > cc -c -I/usr/local/BerkeleyDB/include -std -fprm d -ieee -D_INTRINSICS > -I/usr/l > ocal/include -DLANGUAGE_C -O4 -DVERSION=\"1.810\" > -DXS_VERSION=\"1.810\" "-I/ > usr/local/lib/perl5/5.6.1/alpha-dec_osf/CORE" -D_NOT_CORE > -DmDB_Prefix_t=size_ > t -DmDB_Hash_t=u_int32_t version.c > /usr/local/bin/perl /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp > -noprototypes -ty > pemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap -typemap typemap > DB_File.xs > > DB_File.xsc && mv DB_File.xsc DB_File.c > cc -c -I/usr/local/BerkeleyDB/include -std -fprm d -ieee -D_INTRINSICS > -I/usr/l > ocal/include -DLANGUAGE_C -O4 -DVERSION=\"1.810\" > -DXS_VERSION=\"1.810\" "-I/ > usr/local/lib/perl5/5.6.1/alpha-dec_osf/CORE" -D_NOT_CORE > -DmDB_Prefix_t=size_ > t -DmDB_Hash_t=u_int32_t DB_File.c > Running Mkbootstrap for DB_File () > chmod 644 DB_File.bs > ar cr tmp.a version.o DB_File.o > : tmp.a > rm -f blib/arch/auto/DB_File/DB_File.so > LD_RUN_PATH="/usr/shlib" ld -shared -expect_unresolved "*" -O4 -msym > -std -s -L > /usr/local/lib -all tmp.a -none -o blib/arch/auto/DB_File/DB_File.so > -ldb > chmod 755 blib/arch/auto/DB_File/DB_File.so > cp DB_File.bs blib/arch/auto/DB_File/DB_File.bs > chmod 644 blib/arch/auto/DB_File/DB_File.bs > Manifying blib/man3/DB_File.3 > <ht000@tortuga:/home/ht000/.cpan/build/DB_File-1.810:!>$ or$ make test > Running Mkbootstrap for DB_File () > chmod 644 DB_File.bs > ar cr tmp.a version.o DB_File.o > : tmp.a > rm -f blib/arch/auto/DB_File/DB_File.so > LD_RUN_PATH="/usr/shlib" ld -shared -expect_unresolved "*" -O4 -msym > -std -s -L > /usr/local/lib -all tmp.a -none -o blib/arch/auto/DB_File/DB_File.so > -ldb > chmod 755 blib/arch/auto/DB_File/DB_File.so > cp DB_File.bs blib/arch/auto/DB_File/DB_File.bs > chmod 644 blib/arch/auto/DB_File/DB_File.bs > PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harne > ss(0, 'blib/lib', 'blib/arch')" t/*.t > t/db-btree....ok > > t/db-hash.....dubious > > Test returned status -1 (wstat 139, 0x8b) > Executing /usr/bin/dbx "/usr/local/bin/perl" "core" (where)... > dbx version 5.1 > Type 'help' for help. > Core file created by program "perl" > > signal Segmentation fault at >*[__free_ovflpage, 0x3ff810cb040] > ldl t > 2, 24(a1)
> > 0 __free_ovflpage(0x3ff810c63dc, 0x2, 0x3ff810c6b34, 0x140205408,
> 0x1401fec40 > ) [0x3ff810cb040] > 1 __big_delete(0x3ff810c429c, 0x14021a80a, 0x1, 0x4, 0x1401fec40) > [0x3ff810c6 > b50] > 2 (unknown)() [0x3ff810c4298] > > /usr/bin/dbx: fatal error: hit EOF on standard input file > > t/db-recno.... > make: *** [test_dynamic] Interrupt