Skip Menu |
 

This queue is for tickets about the DBD-Pg CPAN distribution.

Report information
The Basics
Id: 59480
Status: open
Worked: 2 hours (120 min)
Priority: 0/
Queue: DBD-Pg

People
Owner: Nobody in particular
Requestors: IME [...] cpan.org
Cc: imesmits [...] xs4all.nl
AdminCc:

Bug Information
Severity: Critical
Broken in: 2.17.1
Fixed in: (no value)



CC: imesmits [...] xs4all.nl
Subject: DBD::Pg segfault near dbdimp.c:312 under mod_perl w/stacktrace
Download (untitled) / with headers
text/plain 4.1k
In a mod_perl under some conditions an apache2 process crashes with signal 11 (SEGV). This happens when postgres notifies the webserver of underlying schema changes triggered by executing a prepare_cached statement; the app tries to resolve the error by issueing an automated disconnect/connect. Although the connect runs fine, the first execution after the reconnect dumps core in XS function pg_warn. Development box runs FC13, DBD::Pg 1.17.1 on perl 5.10.0 FATAL ERROR Program received signal SIGSEGV, Segmentation fault. 0xb6213bd2 in pg_warn (arg=0x2dcb890, message=0x2ebc492 "column number 23 is out of range 0..-1\n") at dbdimp.c:312 PROBABLE SUSPECT SvROK(SvMAGIC(SvRV(tmp))->mg_obj) CONTEXT FROM dbdimmp.c line 312 static void pg_warn (void * arg, const char * message) { dTHX; SV *tmp; tmp = sv_2mortal(newRV_inc((SV *)arg)); /* This fun little bit is to prevent a core dump when the following occurs: client_min_messages is set to DEBUG3 or greater, and we exit without a disconnect. DBI issues a 'rollback' in this case, which causes some debugging messages to be emitted from the server (such as "StartTransactionCommand"). However, we can't do the D_imp_dbh call anymore, because the underlying dbh has lost some of its magic. Unfortunately, DBI then coredumps in dbh_getcom2. Hence, we make sure that the object passed in is still 'valid', in that a certain level has a ROK flag. If it's not, we just return without issuing any warning, as we can't check things like DBIc_WARN. There may be a better way of handling all this, and we may want to default to always warn() - input welcome. */ if (!SvROK(SvMAGIC(SvRV(tmp))->mg_obj)) { return; } GDB STACKTRACE #0 0xb6213bd2 in pg_warn (arg=0x2dcb890, message=0x2ebc492 "column number 23 is out of range 0..-1\n") at dbdimp.c:312 #1 0xb5f9de09 in defaultNoticeReceiver (arg=0x0, res=0x2f07360) at fe-connect.c:3758 #2 0xb5fa150c in pqInternalNotice (hooks=0x2f679ac, fmt=0xb5fb1dc8 "column number %d is out of range 0..%d") at fe-exec.c:842 #3 0xb5fa18de in check_field_number (res=<value optimized out>, field_num=<value optimized out>) at fe-exec.c:2453 #4 0xb5fa1afd in PQfname (res=0x2f67948, field_num=23) at fe-exec.c:2506 #5 0xb6216008 in pg_st_FETCH_attrib (sth=0x2eafcc0, imp_sth=0x2e94868, keysv=0x2ec5088) at dbdimp.c:1059 #6 0xb61f986b in XS_DBD__Pg__st_FETCH_attrib (my_perl=0x1791d30, cv=0x1809cc0) at Pg.xsi:732 #7 0xb6d499ca in XS_DBI_dispatch (my_perl=<value optimized out>, cv=<value optimized out>) at DBI.xs:3292 #8 0xb7a1f6ab in Perl_pp_entersub (my_perl=0x1791d30) at pp_hot.c:2888 #9 0xb6241347 in pp_subcall_profiler (my_perl=0x1791d30, is_slowop=0) at NYTProf.xs:2457 #10 0xb7a1d818 in Perl_runops_standard (my_perl=0x1791d30) at run.c:40 #11 0xb79be6d1 in Perl_call_sv (my_perl=0x1791d30, sv=0x2e98f80, flags=64) at perl.c:2702 #12 0xb79c0ce4 in Perl_call_method (my_perl=0x1791d30, methname=0xb7abd2e8 "FETCH", flags=0) at perl.c:2633 #13 0xb7a0f577 in S_magic_methcall (my_perl=0x1791d30, sv=0x2ea8ca8, mg=0x2ec44b0, meth=0xb7abd2e8 "FETCH", flags=0, n=2, val=0x0) at mg.c:1698 #14 0xb7a0faf6 in S_magic_methpack (my_perl=0x1791d30, sv=0x2ea8ca8, mg=0x2ec44b0, meth=0xb7abd2e8 "FETCH") at mg.c:1712 #15 0xb7a0fcd9 in Perl_magic_getpack (my_perl=0x1791d30, sv=0x2ea8ca8, mg=0x2ec44b0) at mg.c:1729 #16 0xb7a13588 in Perl_mg_get (my_perl=0x1791d30, sv=0x2ea8ca8) at mg.c:221 #17 0xb7a315d7 in Perl_sv_setsv_flags (my_perl=0x1791d30, dstr=0x2f63fc0, sstr=<value optimized out>, flags=18) at sv.c:3714 #18 0xb7a31e83 in Perl_newSVsv (my_perl=0x1791d30, old=0x2ea8ca8) at sv.c:7723 #19 0xb6d424b0 in XS_DBD_____st_fetchrow_hashref (my_perl=<value optimized out>, cv=<value optimized out>) at DBI.xs:4777 #20 0xb6d499ca in XS_DBI_dispatch (my_perl=<value optimized out>, cv=<value optimized out>) at DBI.xs:3292 #21 0xb7a1f6ab in Perl_pp_entersub (my_perl=0x1791d30) at pp_hot.c:2888 #22 0xb7a1d818 in Perl_runops_standard (my_perl=0x1791d30) at run.c:40 ... #34 0x0014c2ca in child_main (child_num_arg=<value optimized out>) at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:662
Download (untitled) / with headers
text/plain 246b
ADDITIONAL NOTE This might as well be a GC problem either in DBI or DBD::Pg as a DBI->visit_handles(sub { $_[0]->DESTROY; return 1; }) ran before disconnect() seems to at least mitigate or prevent a subsequent core dump on the next execute().


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.