Re: Backend Crash v8.4.2

On Tue, Jun 29, 2010 at 9:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kelly Burkhart <kelly(dot)burkhart(at)gmail(dot)com> writes:
>> The crash left a core file, does the stack trace indicate anything crucial?
>
>> (gdb) where
>> #0  0x000000000068d884 in SearchCatCacheList ()
>> #1  0x0000000100000000 in ?? ()
>> #2  0x0000000000bbcbe0 in ?? ()
>> #3  0x00007f3b3a86a580 in ?? ()
>> #4  0x72ddbea20068dae0 in ?? ()
>> #5  0x00007fff78faa720 in ?? ()
>> #6  0x0000000000000000 in ?? ()
>> Current language:  auto
>> The current source language is "auto; currently asm".
>
> That's pretty much useless unless you can install debug symbols and
> try again.  I will say though that this is probably a new bug ---
> I don't recall seeing anything crashing in SearchCatCacheList recently.

I had our system people install the debug symbols and I get the same
stack trace. I believe the symbols are indeed installed, yesterday
when I started gdb I saw a bunch of lines like this:

Missing separate debuginfo for /usr/lib64/libssl.so.0.9.8
Try: zypper install -C
"debuginfo(build-id)=c1d9e2a7e013149b5acc4d3580724d4827f5827c"

I don't see that now.

>
>> Can anyone provide some guidance on how I can go about discovering the
>> cause?
>
> Please try to create a reproducible test case.  One thing you can get to
> start from is the query that was being executed --- try this in gdb:
>
>        p debug_query_string

I was able to see the query:

select sd.close, s.minimum_trade_increment
from symbol_daily sd, symbol s
where s.symbol_name = sd.symbol_name
and s.exchange_name = sd.exchange_name
and sd.symbol_name = $1
and sd.trading_dt = last_trading_dt()

It's a well established query done probably several times each
morning. I don't know how to create a reproducible test case as I
can't determine anything that we did yesterday that was any different
from any other day.

-K