From: | Sam Stearns <samtstearns(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: [PERFORM] Query Core Dumping |
Date: | 2011-02-09 00:07:50 |
Message-ID: | AANLkTi=FcFV_wcQP_92udYGOvwE_hTEYXrKuGLNYTABs@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-performance |
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 ()
Sam
On Wed, Feb 9, 2011 at 10:33 AM, Sam Stearns <samtstearns(at)gmail(dot)com> wrote:
> Thanks, Tom. Forwarded from pgsql-performance. Working on stack
> trace. perl -V:
>
>> 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
> .
>>
>
> Sam
>
> On Wed, Feb 9, 2011 at 10:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Sam Stearns <samtstearns(at)gmail(dot)com> writes:
>>> 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.
>>
>> Can you get a stack trace from one of the core dumps?
>>
>> Also, exactly which perl version are you using, and with what build
>> options? ("perl -V" output would be a good answer here.)
>>
>> BTW, this seems pretty off-topic for pgsql-performance.
>>
>> regards, tom lane
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Stearns | 2011-02-09 00:33:05 | Re: [PERFORM] Query Core Dumping |
Previous Message | Sam Stearns | 2011-02-09 00:03:04 | Re: [PERFORM] Query Core Dumping |
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Stearns | 2011-02-09 00:33:05 | Re: [PERFORM] Query Core Dumping |
Previous Message | Sam Stearns | 2011-02-09 00:03:04 | Re: [PERFORM] Query Core Dumping |