Red Hat Bugzilla – Bug 188723
Last modified: 2010-03-04 04:15:01 EST
+++ 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) &&
| (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
| #3 0x400af782 in Perl_pp_entersub () from
| #4 0x40092b2d in Perl_runops_debug () from
| #5 0x4003da46 in Perl_get_cv () from
| #6 0x40043b7b in Perl_call_sv () from
| #7 0x40044061 in Perl_call_method () from
| #8 0x40588eaa in XS_DBD_____st_fetchrow_hashref () from
| #9 0x4057f7c2 in XS_DBI_dispatch () from
| #10 0x400af782 in Perl_pp_entersub () from
| #11 0x40092b2d in Perl_runops_debug () from
| #12 0x40044b41 in perl_run () from
| #13 0x080493a2 in main ()
Upstream 1.32 fixes it.
Version-Release number of selected component (if applicable):
-- Additional comment from firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org on 2005-01-18
19:14 EST --
is there a chance to fix this before FC4?
-- Additional comment from email@example.com 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 firstname.lastname@example.org on 2005-04-26 16:53 EST --
Does the new version in FC4 solve this problem?
-- Additional comment from email@example.com on 2005-05-16 05:06 EST --
No response in a while. Closing.
*** Bug 188312 has been marked as a duplicate of this bug. ***
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:
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.
Don't know why that showed up at a bugzilla link... the CPAN bug is located at:
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 "?".
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.