Обсуждение: Perl Libraries and Postgres
Howdy, Environment: Postgres 8.3.13 Solaris 10 I have a SELECT query that runs no problem standalone but when running within a perl script it intermittently core dumps. Random, no pattern to the timing of the core dumps. The perl script processes the rows from the query, if the rows satisfy a condition then the perl script adds the rows to another table. When the script works it runs for about a minute. If the script fails, it runs for about 5 minutes and core dumps. The core dump is in the perl error handling routines. We suspect the bug is related to how the perl postgres libraries interact with postgres. Trace: Segmentation Fault - core dumped =================================== > pollsys(0x080475B8, 1, 0x00000000, 0x00000000) = 1 > recv(4, " i t z _ l i s a @ h o t".., 16005, 0) = 8192 > brk(0x095FBCF0) = 0 > brk(0x095FDCF0) = 0 > pollsys(0x080475B8, 1, 0x00000000, 0x00000000) = 1 > recv(4, "\0\0\007 U L L - N S W\0".., 16278, 0) = 3404 > brk(0x095FDCF0) = 0 > brk(0x095FFCF0) = 0 > Incurred fault #6, FLTBOUNDS %pc = 0x080BF4EF > siginfo: SIGSEGV SEGV_MAPERR addr=0x00000168 > Received signal #11, SIGSEGV [default] > siginfo: SIGSEGV SEGV_MAPERR addr=0x00000168 > =================================== From gdb: #0 0x080bf4ef in Perl_sv_vcatpvfn () #1 0x080bdb30 in Perl_sv_vsetpvfn () #2 0x080a1363 in Perl_vmess () #3 0x080a1d06 in Perl_vwarn () #4 0x080a1fde in Perl_warn () #5 0xfe7f9d58 in pg_warn () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBD/Pg/Pg.so #6 0xfe7c704e in defaultNoticeReceiver () from /usr/local/lib/libpq.so.4 #7 0xfe7cf0bc in pqGetErrorNotice3 () from /usr/local/lib/libpq.so.4 #8 0xfe7cf67f in pqParseInput3 () from /usr/local/lib/libpq.so.4 #9 0xfe7c8398 in parseInput () from /usr/local/lib/libpq.so.4 #10 0xfe7c8c63 in PQgetResult () from /usr/local/lib/libpq.so.4 #11 0xfe7c8d5b in PQexecFinish () from /usr/local/lib/libpq.so.4 #12 0xfe7fdcc1 in dbd_st_execute () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBD/Pg/Pg.so #13 0xfe7f512f in XS_DBD_Pg_db_selectall_arrayref () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBD/Pg/Pg.so #14 0xfecfb301 in XS_DBI_dispatch () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBI/DBI.so #15 0x080b3609 in Perl_pp_entersub () #16 0x080ad365 in Perl_runops_standard () #17 0x08068814 in S_run_body () #18 0x0806852b in perl_run () #19 0x08065ae0 in main () > perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.10, archname=i86pc-solaris uname='sunos katana7 5.10 generic_118855-15 i86pc i386 i86pc ' config_args='-de -A prepend:libswanted=db -Dlocincpth=/usr/local/include/db_185 -Dloclibpth=/usr/local/lib/db_185 -Dcc=gcc -Dprefix=/usr/local/stow/perl-5.8.8' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include/db_185 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV', optimize='-O', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include/db_185' ccversion='', gccversion='3.4.3 (csl-sol210-3_4-branch+sol_rpath)', gccosandvers='solaris2.10' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib/db_185 ' libpth=/usr/local/lib/db_185 /usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib/db_185' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at Aug 29 2006 21:33:23 @INC: /usr/local/stow/perl-5.8.8/lib/5.8.8/i86pc-solaris /usr/local/stow/perl-5.8.8/lib/5.8.8 /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8 /usr/local/stow/perl-5.8.8/lib/site_perl . > Anyone have any ideas? Thanks, Sam
Moin, > Howdy, > > Environment: > > Postgres 8.3.13 > Solaris 10 > > I have a SELECT query that runs no problem standalone but when running > within a perl script it intermittently core dumps. Random, no pattern > to the timing of the core dumps. The perl script processes the rows > from the query, if the rows satisfy a condition then the perl script > adds the rows to another table. When the script works it runs for > about a minute. If the script fails, it runs for about 5 minutes and > core dumps. The core dump is in the perl error handling routines. We > suspect the bug is related to how the perl postgres libraries interact > with postgres. This might be more a question for a perl group. >> perl -V > Summary of my perl5 (revision 5 version 8 subversion 8) configuration: May be an upgrade to 5.10 will solve the problem ? > Anyone have any ideas? see above ;-) Regards Norbert
Thanks, Norbert! I'll run the perl 5.10 upgrade past the guys. Sam On Thu, Feb 10, 2011 at 6:27 PM, Norbert Zacharias <zac@uni-oldenburg.de> wrote: > Moin, > >> Howdy, >> >> Environment: >> >> Postgres 8.3.13 >> Solaris 10 >> >> I have a SELECT query that runs no problem standalone but when running >> within a perl script it intermittently core dumps. Random, no pattern >> to the timing of the core dumps. The perl script processes the rows >> from the query, if the rows satisfy a condition then the perl script >> adds the rows to another table. When the script works it runs for >> about a minute. If the script fails, it runs for about 5 minutes and >> core dumps. The core dump is in the perl error handling routines. We >> suspect the bug is related to how the perl postgres libraries interact >> with postgres. > > This might be more a question for a perl group. > >>> perl -V >> Summary of my perl5 (revision 5 version 8 subversion 8) configuration: > > May be an upgrade to 5.10 will solve the problem ? > >> Anyone have any ideas? > > see above ;-) > > Regards > Norbert > >
On Thu, Feb 10, 2011 at 03:24, Sam Stearns <samtstearns@gmail.com> wrote: > Thanks, Norbert! > > I'll run the perl 5.10 upgrade past the guys. > > Sam > > On Thu, Feb 10, 2011 at 6:27 PM, Norbert Zacharias <zac@uni-oldenburg.de> wrote: >>>> perl -V >>> Summary of my perl5 (revision 5 version 8 subversion 8) configuration: >> >> May be an upgrade to 5.10 will solve the problem ? Doubtful :-( >> From gdb: >> #0 0x080bf4ef in Perl_sv_vcatpvfn () >> #1 0x080bdb30 in Perl_sv_vsetpvfn () >> #2 0x080a1363 in Perl_vmess () >> #3 0x080a1d06 in Perl_vwarn () >> #4 0x080a1fde in Perl_warn () >> #5 0xfe7f9d58 in pg_warn () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBD/Pg/Pg.so >> #6 0xfe7c704e in defaultNoticeReceiver () from /usr/local/lib/libpq.so.4 >> #7 0xfe7cf0bc in pqGetErrorNotice3 () from /usr/local/lib/libpq.so.4 .... So it looks like it you are receiving a notice and DBD::Pg is trying to warn() it. What versions of DBD::Pg and DBI are you using? I'd look at http://cpansearch.perl.org/src/TURNSTEP/DBD-Pg-2.17.2/Changes and http://search.cpan.org/~timb/DBI-1.616/Changes for any known bugs you might be hitting. If upgrading those do not fix it, the next step would be to try and make a reproducible test case. I'd start by by cranking up the postgres log level so you can find out what the notice is. From there you might be able to find a way to trigger it reliably. If all else fails it never hurts to run it under valgrind to see if it can pinpoint some obvious memory corruption.
Thanks, Alex! I will take a look at your recommendations and keep you posted. Sam On Sat, Feb 12, 2011 at 3:28 AM, Alex Hunsaker <badalex@gmail.com> wrote: > On Thu, Feb 10, 2011 at 03:24, Sam Stearns <samtstearns@gmail.com> wrote: >> Thanks, Norbert! >> >> I'll run the perl 5.10 upgrade past the guys. >> >> Sam >> >> On Thu, Feb 10, 2011 at 6:27 PM, Norbert Zacharias <zac@uni-oldenburg.de> wrote: > >>>>> perl -V >>>> Summary of my perl5 (revision 5 version 8 subversion 8) configuration: >>> >>> May be an upgrade to 5.10 will solve the problem ? > > Doubtful :-( > >>> From gdb: > >>> #0 0x080bf4ef in Perl_sv_vcatpvfn () >>> #1 0x080bdb30 in Perl_sv_vsetpvfn () >>> #2 0x080a1363 in Perl_vmess () >>> #3 0x080a1d06 in Perl_vwarn () >>> #4 0x080a1fde in Perl_warn () >>> #5 0xfe7f9d58 in pg_warn () from /usr/local/stow/perl-5.8.8/lib/site_perl/5.8.8/i86pc-solaris/auto/DBD/Pg/Pg.so >>> #6 0xfe7c704e in defaultNoticeReceiver () from /usr/local/lib/libpq.so.4 >>> #7 0xfe7cf0bc in pqGetErrorNotice3 () from /usr/local/lib/libpq.so.4 > .... > > So it looks like it you are receiving a notice and DBD::Pg is trying > to warn() it. > > What versions of DBD::Pg and DBI are you using? I'd look at > http://cpansearch.perl.org/src/TURNSTEP/DBD-Pg-2.17.2/Changes and > http://search.cpan.org/~timb/DBI-1.616/Changes for any known bugs you > might be hitting. > > If upgrading those do not fix it, the next step would be to try and > make a reproducible test case. I'd start by by cranking up the > postgres log level so you can find out what the notice is. From there > you might be able to find a way to trigger it reliably. > > If all else fails it never hurts to run it under valgrind to see if it > can pinpoint some obvious memory corruption. >