Re: segmentation fault postgres 9.3.5 core dump perlu related ? - Mailing list pgsql-general

From Day, David
Subject Re: segmentation fault postgres 9.3.5 core dump perlu related ?
Date
Msg-id 401084E5E73F4241A44F3C9E6FD794280115848433@exch-01
Whole thread Raw
In response to Re: segmentation fault postgres 9.3.5 core dump perlu related ?  (Guy Helmer <ghelmer@palisadesystems.com>)
List pgsql-general

Guy,

 

No I had not seen that bug report before.  ( https://rt.perl.org/Public/Bug/Display.html?id=122199 )

 

We did migrate from FreeBSD 9.x (2?) and I think it true

that we were not experiencing the problem at time.

So it might be a good fit/explanation for our current experience

 

There were a couple of suggestions to follow up on.

I’ll keep the thread updated.

 

Thanks, a  good start to my  Friday the 13th.

 

 

Regards

 

 

Dave Day

 

 

 

 

 

From: Guy Helmer [mailto:ghelmer@palisadesystems.com]
Sent: Thursday, February 12, 2015 6:19 PM
To: Day, David
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

 

 

On Feb 12, 2015, at 3:21 PM, Day, David <dday@redcom.com> wrote:

 

Update/Information sharing on my pursuit of  segmentation faults

 

FreeBSD 10.0-RELEASE-p12 amd64

Postgres version 9.3.5

 

Below are three postgres core files generated from two different machine ( Georgia and Alabama ) on Feb 11. 

These cores would not be caused  from an  environment update issue that I last suspected might be causing the segfaults

So I am kind of back to square one in terms of thinking what is occurring.

 

?  I am not sure that I understand the associated time events in the  postgres log file output.  Is this whatever happens to be running on the other postgress forked process when the cored  process was detected ? 

If this is the case then I have probably been reading to much from the content of the postgres log file at the time of core.

This probably just represents collateral damage of routine transactions that were in other forked  processes at the time one of the processes cored ?

 

Therefore I would now just assert  that postgres has a sporadic segmentation problem,  no known way to reliably cause it 

and am uncertain as to how to proceed to resolve it. 

 

. . .



 Georgia-Core 8:38 -  Feb 11

[New process 101032]

[New Thread 802c06400 (LWP 101032)]

Core was generated by `postgres'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x000000080c4b6d51 in Perl_hfree_next_entry () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

(gdb) bt

#0  0x000000080c4b6d51 in Perl_hfree_next_entry () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

#1  0x000000080c4cab49 in Perl_sv_clear () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

#2  0x000000080c4cb13a in Perl_sv_free2 () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

#3  0x000000080c4e5102 in Perl_free_tmps () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

#4  0x000000080bcfedea in plperl_destroy_interp () from /usr/local/lib/postgresql/plperl.so

#5  0x000000080bcfec05 in plperl_fini () from /usr/local/lib/postgresql/plperl.so

#6  0x00000000006292c6 in ?? ()

#7  0x000000000062918d in proc_exit ()

#8  0x00000000006443f3 in PostgresMain ()

#9  0x00000000005ff267 in PostmasterMain ()

#10 0x00000000005a31ba in main ()

(gdb) info threads

  Id   Target Id         Frame

* 2    Thread 802c06400 (LWP 101032) 0x000000080c4b6d51 in Perl_hfree_next_entry () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

* 1    Thread 802c06400 (LWP 101032) 0x000000080c4b6d51 in Perl_hfree_next_entry () from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

 

 

Given two of the coredumps are in down in libperl and this is FreeBSD 10.0 amd64, have you seen this? 

 

 

Michael Moll suggested trying setting vm.pmap.pcid_enabled to 0 but I don’t recall seeing if that helped.

 

Guy

 

 

pgsql-general by date:

Previous
From: "Bald, Glenn"
Date:
Subject: Unknown error while running <> postgresql_installer_dc46cfee2c\getlocales.exe
Next
From: Pavel Stehule
Date:
Subject: Re: Collection