Bug 188723

Summary: perl-DBD-Pg segfaults
Product: Red Hat Enterprise Linux 4 Reporter: Jason Vas Dias <jvdias>
Component: perl-DBD-PgAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: admin, dkl, mariano.cano, mmaslano, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-04 09:15:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 127755    
Bug Blocks:    

Description Jason Vas Dias 2006-04-12 16:36:01 UTC
+++ This bug was initially created as a clone of Bug #127755 +++

Description of problem:

When using 'autodoc' (http://www.rbt.ca/autodoc/index.html) on one of
my databases, I get a segfault at:

| Program received signal SIGSEGV, Segmentation fault.
| [Switching to Thread 16384 (LWP 3444)]
| dbd_st_fetch (sth=0x82737e8, imp_sth=0x8269188) at dbdimp.c:1039
| 1039                            if ((type_info->type_id == BPCHAROID) &&
chopblanks) {
| (gdb) p type_info
| $1 = (sql_type_info_t *) 0x0
| (gdb) bt
| #0  dbd_st_fetch (sth=0x82737e8, imp_sth=0x8269188) at dbdimp.c:1039
| #1  0x405a4244 in XS_DBD__Pg__st_fetchrow_arrayref (my_perl=0x804c3c8,
cv=0x804c3c8) at Pg.xsi:541
| #2  0x4057f7c2 in XS_DBI_dispatch () from
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi/auto/DBI/DBI.so
| #3  0x400af782 in Perl_pp_entersub () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #4  0x40092b2d in Perl_runops_debug () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #5  0x4003da46 in Perl_get_cv () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #6  0x40043b7b in Perl_call_sv () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #7  0x40044061 in Perl_call_method () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #8  0x40588eaa in XS_DBD_____st_fetchrow_hashref () from
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi/auto/DBI/DBI.so
| #9  0x4057f7c2 in XS_DBI_dispatch () from
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi/auto/DBI/DBI.so
| #10 0x400af782 in Perl_pp_entersub () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #11 0x40092b2d in Perl_runops_debug () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #12 0x40044b41 in perl_run () from
/usr/lib/perl5/5.8.4/i386-linux-thread-multi/CORE/libperl.so
| #13 0x080493a2 in main ()


Upstream 1.32 fixes it.



Version-Release number of selected component (if applicable):

perl-DBD-Pg-1.31-6.1


How reproducible:

100%

-- Additional comment from cturner on 2004-07-26 08:39 EST --
can you provide a smaller test case (preferably a script of a few
lines that reproduces it on a clean install)?

-- Additional comment from enrico.scholz.de on 2004-07-26
19:46 EST --
Would it be really worth the effort to search a minimal example when
the current stable release fixes the segfault?

-- Additional comment from enrico.scholz.de on 2005-01-18
19:14 EST --
is there a chance to fix this before FC4?

-- Additional comment from enrico.scholz.de on 2005-02-15
16:32 EST --
Is it really so difficulty to download a file and adjust the Version: field? Or
why does this bug stay for more than 7 months unresolved?

-- Additional comment from wtogami on 2005-04-26 16:53 EST --
Does the new version in FC4 solve this problem?


-- Additional comment from wtogami on 2005-05-16 05:06 EST --
No response in a while.  Closing.

Comment 1 Jason Vas Dias 2006-04-12 16:45:56 UTC
*** Bug 188312 has been marked as a duplicate of this bug. ***

Comment 2 Jason Vas Dias 2006-04-12 19:24:58 UTC
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.

Comment 4 Brian Carp 2006-05-30 17:10:49 UTC
There are all sort of problems with DBD::Pg version 1.31.

Red Hat SHOULD build an rpm for version 1.43 (the latest version that doesn't break on the 
"'DBIcf_PrintWarn' undeclared" compile problem [cpan bug #18260]) and provide that as an update.

For example, a call to 'execute' with bind paramaters will fail for integers (the only workaround is 
to call 'bind_param' and force typing with the SQL_INTEGER constant).  The bug probably exists 
through the code overhaul that took place for version 1.40.

I was only able to solve my segfaulting problems by download DBD-Pg-1.43 from CPAN and 
installing it into the 'site_perl' tree to override the RHEL4 version in the 'vendor_perl' tree.  YMMV.

Comment 5 Brian Carp 2006-05-30 17:16:40 UTC
Don't know why that showed up at a bugzilla link... the CPAN bug is located at:

http://rt.cpan.org/Public/Bug/Display.html?id=18260

Comment 7 RHEL Program Management 2008-04-16 09:38:37 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 9 RHEL Program Management 2008-10-31 16:35:59 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 10 RHEL Program Management 2010-03-04 09:15:01 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.