Re: pq_recvbuf: unexpected EOF
От | David Link |
---|---|
Тема | Re: pq_recvbuf: unexpected EOF |
Дата | |
Msg-id | 20030428175215.45418.qmail@web13509.mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: pq_recvbuf: unexpected EOF (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
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@sss.pgh.pa.us> wrote: > David Link <dvlink@yahoo.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
В списке pgsql-general по дате отправления: