> On Feb 12, 2015, at 3:21 PM, Day, David <d...@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? https://rt.perl.org/Public/Bug/Display.html?id=122199 <https://rt.perl.org/Public/Bug/Display.html?id=122199> Michael Moll suggested trying setting vm.pmap.pcid_enabled to 0 but I don’t recall seeing if that helped. Guy
