Description of problem: Segmentation fault when using perl-DBD-1.31-6 on RHEL4U2 and database postgresql-7.4.8-1.RHEL4.1 and perl-5.8.5 If I download the vanilla DBD-1.32.tar.gz from CPAN, build and install, the segmentation fault doesn't occur. Could this be because the current perl-DBD-Pg package we ship is built against perl-5.8.3 and the latest perl is 5.8.5? Would a strace dump be helpful?
Hi Dave - yes, please supply some further information - 1. A perl program / command that generates the core dump 2. The exact perl, perl-DBI, perl-DBD-Pg, versions you are using : # rpm -q perl perl-DBI perl-DBD-Pg postgresql-libs --qf "%{NAME} %{VERSION} %{RELEASE} %{ARCH}\n" 3. The machine architecture 3. A core dump from the command: # ulimit -c unlimited; $command # gzip -c core.* and please append the core.*.gz file Or, since we're both here at Red Hat, perhaps a login to the machine so I can debug ? I've just verified that this problem does NOT occur with the U3 RPMS on i386: perl-5.8.5-24.RHEL-4.i386 perl-DBI-1.40-8.i386 perl-DBD-Pg-1.31-6 postgresql-libs-7.4.8-1.RHEL4 and a simple test program like: --- #!/usr/bin/perl use DBI; use DBD::Pg; $dbh = DBI->connect('dbi:Pg:dbname=db;', 'root', '') || die("can't connect: $! $?"); my $stmt = $dbh->prepare("SELECT * FROM t WHERE c = ?"); my $rv = $stmt->execute("A"); print 'RV:',$rv,"\n"; while (my $data = $stmt->fetchrow_hashref) { print join(" ",values %{$data}),"\n"; }; $dbh->disconnect(); ---
Here is a trace using gdb of the bug: [root@localhost ~]# gdb perl GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r test_db.pl Starting program: /usr/bin/perl test_db.pl (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208428864 (LWP 10297)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) DBI 1.40-ithread dispatch trace level set to 1 (in pid 10297) -> DBI->connect(dbi:Pg:dbname=magnus host=database, postgres, ****) -> DBI->install_driver(Pg) for linux perl=5.008005 pid=10297 ruid=0 euid=0 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) install_driver: DBD::Pg version 1.31 loaded from /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/DBD/Pg.pm <- install_driver= DBI::dr=HASH(0x8e468a8) pg_db_login (no debugging symbols found) dbd_db_STORE dbd_db_STORE dbd_db_STORE <- connect= DBI::db=HASH(0x8ed57f0) dbd_db_STORE dbd_st_prepare: statement = >SELECT conkey FROM pg_constraint WHERE contype='p' limit 10< dbd_st_execute dbd_st_FETCH 1 <- FETCH('NAME')= [ 'conkey' ] at test_db.pl line 17 dbd_st_fetch Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208428864 (LWP 10297)] 0x0052262e in dbd_st_fetch () from /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/auto/DBD/Pg/Pg.so (gdb) backtrace #0 0x0052262e in dbd_st_fetch () from /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/auto/DBD/Pg/Pg.so #1 0x0051737f in XS_DBD__Pg__st_fetchrow_arrayref () from /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/auto/DBD/Pg/Pg.so #2 0x00cef7a2 in XS_DBI_dispatch () from /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DBI.so #3 0x007e49e2 in Perl_pp_entersub () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #4 0x007c7e9d in Perl_runops_debug () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #5 0x00772ae6 in Perl_get_cv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #6 0x00778c88 in Perl_call_sv () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #7 0x00779171 in Perl_call_method () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #8 0x00cf8e6f in XS_DBD_____st_fetchrow_hashref () from /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DBI.so #9 0x00cef7a2 in XS_DBI_dispatch () from /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DBI.so #10 0x007e49e2 in Perl_pp_entersub () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #11 0x007c7e9d in Perl_runops_debug () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #12 0x00779c51 in perl_run () from /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so #13 0x080493a2 in main () (gdb) q
Created attachment 127663 [details] Core dump caused by the segfault of test_db.pl
Created attachment 127664 [details] perl script that causes the segmentation fault
Attached core dump, perl script rpm -q perl perl-DBI perl-DBD-Pg postgresql-libs --qf "%{NAME} %{VERSION} %{RELEASE} %{ARCH}\n" perl 5.8.5 24.RHEL4 i386 perl-DBI 1.40 8 i386 perl-DBD-Pg 1.31 6 i386 postgresql-libs 7.4.8 1.RHEL4.1 i386
Many thanks for the core dump - I see the problem now. While I still cannot reproduce the problem with an empty or very small test database ( the test_db.pl test script runs without errors ) I can install the debuginfo packages and see the point in the code where it cores: #0 dbd_st_fetch (sth=0x9560994, imp_sth=0x961e820) at dbdimp.c:1039 1039 if ((type_info->type_id == BPCHAROID) && chopblanks) { (gdb) print type_info $1 = (sql_time_info_t *) 0x0 It turns out this problem has been reported before (Bug #127755) , for which an update to perl-DBD-Pg-1.32 was submitted to FC-3. Unfortunately, perl-DBD-Pg was never updated in RHEL-4 :-( Closing this bug as a duplicate of the RHEL-4 clone of Bug #127755, (Bug 188723) to reflect the fact that this bug has been fixed before in FC-3. I'll do what I can to get this fixed in a RHEL-4 update ASAP. *** This bug has been marked as a duplicate of 188723 ***
This bug is now fixed with perl-DBD-Pg-1.31-8.EL4 . The NULL type_info occurred because both DBD::Pg 1.31 and 1.32 were missing support for the postgresql 7.4.8 data type ANYELEMENTOID . I've now added support for ANYELEMENTOID to the 1.31 code; so a null type_info should not now occur with postgresql 7.4.8; however, if it does, (eg. by running DBD::Pg 1.31 with postgresql > 7.4.8), I've also backported the null type_info handling from DBD::Pg 1.32's dbdimp.c db_st_fetch function. Please try out the new perl-DBD-Pg-1.31-8.EL4 version and let me know of any issues . You can download it from: http://people.redhat.com/~jvdias/perl-DBD-Pg/RHEL-4 thanks.