Re: Core dump on PG 7.1.3

It's amazing what a man page can teach you ... ;)

[postgres(at)timdb2 2034013]$ gdb /usr/local/pgsql/bin/postgres -c core
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...

warning: core file may not match specified executable file.
Core was generated by `postgres: postgres bnmail [local] UPDATE '.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libreadline.so.4.1...done.
Loaded symbols for /usr/lib/libreadline.so.4.1
Reading symbols from /lib/libtermcap.so.2...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
"") at execQual.c:324
324 tuple_type = slot->ttc_tupleDescriptor;
(gdb) bt
#0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
"") at execQual.c:324
#1 0x080ba4b1 in ExecEvalExpr (expression=0x8237338, econtext=0x8238238,
isNull=0x826769c "", isDone=0xbfffea78)
at execQual.c:1187
#2 0x080b9f03 in ExecEvalFuncArgs (fcache=0x8267638, argList=0x8237360,
econtext=0x8238238) at execQual.c:614
#3 0x080b9f7c in ExecMakeFunctionResult (fcache=0x8267638,
arguments=0x8237360, econtext=0x8238238, isNull=0x8267614 "",
isDone=0xbfffeb38) at execQual.c:667
#4 0x080ba16d in ExecEvalFunc (funcClause=0x82372f8, econtext=0x8238238,
isNull=0x8267614 "", isDone=0xbfffeb38)
at execQual.c:902
#5 0x080ba52d in ExecEvalExpr (expression=0x82372f8, econtext=0x8238238,
isNull=0x8267614 "", isDone=0xbfffeb38)
at execQual.c:1226
#6 0x080b9f03 in ExecEvalFuncArgs (fcache=0x82675b0, argList=0x8237378,
econtext=0x8238238) at execQual.c:614
#7 0x080b9f7c in ExecMakeFunctionResult (fcache=0x82675b0,
arguments=0x8237378, econtext=0x8238238, isNull=0xbfffebfb "",
isDone=0x0) at execQual.c:667
#8 0x080ba119 in ExecEvalOper (opClause=0x82372a8, econtext=0x8238238,
isNull=0xbfffebfb "", isDone=0x0) at execQual.c:860
#9 0x080ba521 in ExecEvalExpr (expression=0x82372a8, econtext=0x8238238,
isNull=0xbfffebfb "", isDone=0x0) at execQual.c:1222
#10 0x080ba632 in ExecQual (qual=0x82373d0, econtext=0x8238238,
resultForNull=0 '\000') at execQual.c:1374
#11 0x080bdf89 in IndexNext (node=0x8236a70) at nodeIndexscan.c:133
#12 0x080baadf in ExecScan (node=0x8236a70, accessMtd=0x80bde8c <IndexNext>)
at execScan.c:95
#13 0x080be160 in ExecIndexScan (node=0x8236a70) at nodeIndexscan.c:283
#14 0x080b9259 in ExecProcNode (node=0x8236a70, parent=0x8233990) at
execProcnode.c:282
#15 0x080bf9d4 in ExecNestLoop (node=0x8233990) at nodeNestloop.c:165
#16 0x080b9295 in ExecProcNode (node=0x8233990, parent=0x8233990) at
execProcnode.c:297
#17 0x080b8ee2 in EvalPlanQualNext (estate=0x8230de0) at execMain.c:1884
#18 0x080b8eba in EvalPlanQual (estate=0x8230de0, rti=1, tid=0xbfffee00) at
execMain.c:1870
#19 0x080b8813 in ExecReplace (slot=0x82313f4, tupleid=0xbfffee90,
estate=0x8230de0) at execMain.c:1465
#20 0x080b84ad in ExecutePlan (estate=0x8230de0, plan=0x82307a8,
operation=CMD_UPDATE, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x82331a0) at execMain.c:1125
#21 0x080b7974 in ExecutorRun (queryDesc=0x8230dc8, estate=0x8230de0,
feature=3, count=0) at execMain.c:233
#22 0x080fc8b7 in ProcessQuery (parsetree=0x8203270, plan=0x82307a8,
dest=Remote) at pquery.c:295
#23 0x080fb3c6 in pg_exec_query_string (
query_string=0x8202a78 "UPDATE campaign_email \nSET
campaign_email_status = 2,\ncampaign_email_last_modified =
message_queue.last_modification \nFROM message_queue,
message_queue_purge_lock \nWHERE message_queue.message_id = mes"...,
dest=Remote,
parse_context=0x81dc6e8) at postgres.c:810
#24 0x080fc3ae in PostgresMain (argc=4, argv=0xbffff150, real_argc=4,
real_argv=0xbffffadc, username=0x81d3261 "postgres")
at postgres.c:1908
#25 0x080e7408 in DoBackend (port=0x81d2ff8) at postmaster.c:2114
#26 0x080e6ffb in BackendStartup (port=0x81d2ff8) at postmaster.c:1897
#27 0x080e6265 in ServerLoop () at postmaster.c:995
#28 0x080e5cb0 in PostmasterMain (argc=4, argv=0xbffffadc) at
postmaster.c:685
#29 0x080c7417 in main (argc=4, argv=0xbffffadc) at main.c:171
#30 0x400ed306 in __libc_start_main (main=0x80c72e4 <main>, argc=4,
ubp_av=0xbffffadc, init=0x8065364 <_init>,
fini=0x813e970 <_fini>, rtld_fini=0x4000d2cc <_dl_fini>,
stack_end=0xbffffacc) at ../sysdeps/generic/libc-start.c:129
(gdb)

> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org]On Behalf Of David Esposito
> Sent: Tuesday, April 02, 2002 9:11 AM
> To: Tom Lane
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> Ok, I'll be the first to admit that my GDB debugging skills are
> not all that
> strong ... ;)
>
> Here's what I did to compile postgres 7.1.3
>
> ./configure --enable-debug
> gmake CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS all
> gmake install
>
> (i could see that it was compiling debug info into the
> executables since the
> "-g" flag was being used with the gcc commands)
>
> So then I fired up postgres and managed to get it to crash again ...
>
> I changed to the directory containing the core dump and ran gdb
>
> gdb -c core
>
> once GDB started, i typed "bt" and, again, i just got the hex
> addresses and
> no pretty function names or line numbers ...
>
> am I doing something wrong?
>
> Core was generated by `postgres: postgres bnmail [local] UPDATE
> '.
> Program terminated with signal 11, Segmentation fault.
> #0 0x080b992b in ?? ()
> (gdb) bt
> #0 0x080b992b in ?? ()
> #1 0x080ba4b1 in ?? ()
> #2 0x080b9f03 in ?? ()
> #3 0x080b9f7c in ?? ()
> #4 0x080ba16d in ?? ()
> #5 0x080ba52d in ?? ()
> #6 0x080b9f03 in ?? ()
> #7 0x080b9f7c in ?? ()
> #8 0x080ba119 in ?? ()
> #9 0x080ba521 in ?? ()
> #10 0x080ba632 in ?? ()
> #11 0x080bdf89 in ?? ()
> #12 0x080baadf in ?? ()
> #13 0x080be160 in ?? ()
> #14 0x080b9259 in ?? ()
> #15 0x080bf9d4 in ?? ()
> #16 0x080b9295 in ?? ()
> #17 0x080b8ee2 in ?? ()
> #18 0x080b8eba in ?? ()
> #19 0x080b8813 in ?? ()
> #20 0x080b84ad in ?? ()
> #21 0x080b7974 in ?? ()
> #22 0x080fc8b7 in ?? ()
> #23 0x080fb3c6 in ?? ()
> #24 0x080fc3ae in ?? ()
> #25 0x080e7408 in ?? ()
> #26 0x080e6ffb in ?? ()
> #27 0x080e6265 in ?? ()
> #28 0x080e5cb0 in ?? ()
> #29 0x080c7417 in ?? ()
> #30 0x400ed306 in ?? ()
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> > Sent: Monday, April 01, 2002 4:17 PM
> > To: David Esposito
> > Cc: pgsql-general(at)postgresql(dot)org
> > Subject: Re: [GENERAL] Core dump on PG 7.1.3
> >
> >
> > "David Esposito" <dvesposito(at)newnetco(dot)com> writes:
> > > However, since this problem needs to be fixed, I see myself being
> > > able to do one of two things ...
> > > - Recompiling PG 7.1.3 using the debug symbols ..
> > > - Upgrading to PG 7.2
> > > Is there anything I'm missing here that I could try that is
> > non-invasive?
> >
> > Recompiling with debug symbols should be reasonably non-invasive,
> > assuming that you can otherwise duplicate the configuration options.
> > (If you're using locally built executables this shouldn't be hard;
> > not sure what's involved if you are using RPMs that came from somewhere
> > else.)
> >
> > Updating to 7.2 would imply a dump and restore, which'd very likely make
> > the problem go away --- but then we'd not learn anything about what
> > caused the crash. If the underlying bug still exists in 7.2 then it
> > might someday bite you again. Are you more interested in getting up and
> > running ASAP, or in helping to debug the problem?
> >
> > regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)