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

Report information
The Basics
Id:
59480
Status:
stalled
Worked:
2 hours (120 minutes)
Users:
IME: 2 hours (120 minutes)
Priority:
Low/Low
Queue:

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

BugTracker
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
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
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().
Moving to stalled, please open again if anyone sees this problem still happening.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

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