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

Alan,

I tried as you suggested,  I believe the gdb debugger is giving some false indication about threads.

Whether I attach to a newly launched  backend or a backend that has been executing the suspect perlu function.

The “info threads” result is two.  Suspiciously  they are both at the same location.

e.g.

* 2    Thread 802c06400 (LWP 101353) 0x000000080bfa50a3 in Perl_fbm_instr ()

   from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

* 1    Thread 802c06400 (LWP 101353) 0x000000080bfa50a3 in Perl_fbm_instr ()

   from /usr/local/lib/perl5/5.18/mach/CORE/libperl.so.5.18

That seemed odd to me.  If we use ‘top’ or ‘ps axuwwH’ to get a thread count for

a given process the indication is only one thread for the same situations.

I am now  pursuing a different causal hypothesis.   There are instances of another

segmentation fault that do not involve this perl fx.  Rather it is a function that

is also called regularly even on a basically idle system.  Therefore it is perhaps  happenstance as

to which kind might happen.   I believe this may relate to our update process.

Product developers are frequently updating (daily)  environments/packages while running postgres and possibly our  application.  I am thinking this update process is not properly coordinating with a running postgres and  may result in occasional  

shared library issues.  This thought is consistent  in  that our production testers who update

at a much lower frequency almost never see this segmentation fault problem but use the same update script.

I’ll attempt some scripts changes and meanwhile ask the developers to make observations that would support this idea.

I’ll update the thread with the future observations/outcome.

Possibly changing the subject to careless developers cause segmentation fault

Thanks for your assistance on this matter.

Dave