Re: pq_recvbuf: unexpected EOF

Here the back trace.
(I rebuilt using --enable-debug and --enable-cassert,
I ran 'ulimit -u unlimited' as root before su'ing to postgres and
starting pg_ctl.
I ran 'ulimit -c unlimited' in the pg_ctl script itself (as postgres)

(gdb) bt
#0 0x4010ba01 in __kill () from /lib/i686/libc.so.6
#1 0x4010b7da in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x4010cf82 in abort () at ../sysdeps/generic/abort.c:88
#3 0x0817b285 in ExceptionalCondition () at assert.c:46
#4 0x081263e6 in UnpinBuffer (buf=0x402a6ea8) at freelist.c:147
#5 0x08125a64 in ReleaseBuffer (buffer=49) at bufmgr.c:1510
#6 0x080e47e7 in ExecClearTuple (slot=0x82d5aec) at execTuples.c:416
#7 0x080e4633 in ExecStoreTuple (tuple=0x82d5cb8, slot=0x82d5aec,
buffer=2013, shouldFree=0 '\000') at execTuples.c:359
#8 0x080ea56f in SeqNext (node=0x82d5854) at nodeSeqscan.c:108
#9 0x080e4309 in ExecScan (node=0x82d5854, accessMtd=0x80ea4e4
<SeqNext>)
at execScan.c:96
#10 0x080ea58b in ExecSeqScan (node=0x82d5854) at nodeSeqscan.c:133
#11 0x080e1dc9 in ExecProcNode (node=0x82d5854, parent=0x82d58e0)
at execProcnode.c:291
#12 0x080e677a in ExecAgg (node=0x82d58e0) at nodeAgg.c:590
#13 0x080e1eb9 in ExecProcNode (node=0x82d58e0, parent=0x0)
at execProcnode.c:357
#14 0x080e0b83 in ExecutePlan (estate=0x82d59c0, plan=0x82d58e0,
operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection,
destfunc=0x82d5e80) at execMain.c:954
#15 0x080e01bd in ExecutorRun (queryDesc=0x82d524c, estate=0x82d59c0,
direction=ForwardScanDirection, count=0) at execMain.c:195
#16 0x081334bf in ProcessQuery (parsetree=0x82cf0c4, plan=0x82d58e0,
dest=Remote, completionTag=0xbfffef30 "") at pquery.c:242
#17 0x08131aa4 in pg_exec_query_string (query_string=0x82cef9c,
dest=Remote,
parse_context=0x82c3fb4) at postgres.c:838
#18 0x08132bc1 in PostgresMain (argc=4, argv=0xbffff160,
username=0x8270321 "video") at postgres.c:2016
#19 0x081181c0 in DoBackend (port=0x82701f0) at postmaster.c:2293
#20 0x08117b12 in BackendStartup (port=0x82701f0) at postmaster.c:1915
#21 0x08116d75 in ServerLoop () at postmaster.c:1018
#22 0x081168ca in PostmasterMain (argc=2, argv=0x8256eb8) at
postmaster.c:779
#23 0x080f3907 in main (argc=2, argv=0xbffffaf4) at main.c:210
#24 0x400f9507 in __libc_start_main (main=0x80f3728 <main>, argc=2,
ubp_av=0xbffffaf4, init=0x806a828 <_init>, fini=0x818db20 <_fini>,
rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffffaec)
at ../sysdeps/generic/libc-start.c:129
(gdb)

--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Link <dvlink(at)yahoo(dot)com> writes:
> > warning: core file may not match specified executable file.
>
> That seems suspicious. You sure you pointed gdb at the correct
> postgres
> executable?
>
> > #0 0x0810e9a3 in ReleaseAndReadBuffer () at eval.c:41
>
> This is pretty obviously bogus, since ReleaseAndReadBuffer isn't in
> eval.c.
>
> It might be that you will need to rebuild postgres with debugging
> symbols before you will get a useful backtrace. I have noticed that
> on
> some platforms, gdb's backtrace from a non-debug-enabled executable
> is not just incomplete but flat-out wrong. This looks like it could
> be one of those cases.
>
> regards, tom lane

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com