Search Postgresql Archives

Re: segmentation fault postgres 9.3.5 core dump perlu related ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

 

 

From: Alex Hunsaker [mailto:badalex@xxxxxxxxx]
Sent: Thursday, January 29, 2015 6:10 PM
To: Day, David
Cc: pgsql-general@xxxxxxxxxxxxxx; Tom Lane
Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

 

 

 

On Thu, Jan 29, 2015 at 1:54 PM, Day, David <dday@xxxxxxxxxx> wrote:

Thanks for the inputs,  I’ll attempt to apply it and will update when I have some new information. 

 

 

BTW a quick check would be to attach with gdb right after you connect, check info threads (there should be none), run the plperlu procedure (with the right arguments/calls to hit all the execution paths), check info threads again. If info threads now reports a thread, we are likely looking at the right plperlu code. It should just be a matter of commenting stuff out to deduce what makes the thread. If not, it could be that plperlu is not at fault and its something else like an extension or some other procedure/pl.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux