Subject: Help!!! Backend core dump

From: "David J. Hughes" <[email-masked]>
Date: Wed, 2 Jun 93 00:48:23 -0700

I am currently seeing the Postgres 4.1 backend dumping core as a result
of the most simple query in my entire application :-

	retrieve (M_USER_INFO.xdisplay)

The last things I see from the backend are :-

	Error: Unexpected response from the backend, exiting...
	Error: Unexpected identfier in dump_data: I

I have also seen 
	Error: Unexpected identfier in dump_data: P

with the same result (ie. a core dump)

This happens on the same query but not every time.  Sometimes, this
piece of code may be executed properly from anywhere between 3 and 5
times.  Othertimes it'll dump on the first execution.  I have included a
stack trace below.

Any help on this, or even just an idea of what the errors may imply,
would be greatly appreciated.

[ on a side note, my code fires off hundreds of queries
without problems.  I can't see why this is causing problems ]

Environment	:-

		Postgres 4.1  via libpq
		Sparc
		SunOS 4.1.1

   ___                                  David J. Hughes    [email-masked]
  /   \                /  /    /        
 /  __/ __   __   ____/  /    / __            Senior Network Programmer
/    \ /  \ /  \ /   /  /    / /  \  /      Comms Development & Operation
\____/ \__//   / \__/   \___/ /   / /   Qld. 4229  AUSTRALIA  (+61 75 951450)

_exit() at 0xf75c3670
ExcRaise() at 0x63548
dump_data() at 0x63f74
process_portal() at 0x5e574
PQexec() at 0x5f3ac
MdbCreateValueList(rel = 0x71511 "M_USER_INFO", field = 0x7151d
	"xdisplay", condition = (nil), sort = 0), line 165 in "db/db_int.c"
reportIt(class = 1, event = 5, message = 0x8df38 "IP Service ftp on
	fiddich went down at  17:27:10  06/02/93 "), line 465 in "alert.c"
processEvent(sd = 5), line 971 in "reporter.c"
main(argc = 1, argv = 0xf7fffe3c), line 1092 in "reporter.c"

---

From: [email-masked] (Paul M. Aoki)
Date: Wed, 02 Jun 93 10:12:55 -0700

> with the same result (ie. a core dump)

these so-helpful messages are indeed the libpq way of telling
you the backend dumped core. :-/  that's about all it can tell
you, too -- there's garbage in the fd.

a general point for everyone: when submitting bug reports, it's
important to send a stack trace from *the backend core*.  when
the backend barfs, it leaves a core in its working directory
($PGDATA/base/<your-database-name>); the output of the command
"where" given to either
	dbx `which postgres` core
or
	gdb `which postgres` core
is what i'm talking about.

and as with any other bug report, enclosing a (minimally-sized)
data set/schema description/set of queries that reproduces the 
problem will also bump the priority up considerably.  (for 
example, when the ultrix 4.3 shmat() bug hit us, we had to provide 
a 4-line program that reproduced the problem before DEC would look 
at the SPR.  saying "shmat loses when called with an OMAGIC file 
and these arguments" was not enough.)

the reason for this is pretty obvious.  if you don't boil it down
to something anyone can reproduce, then you've just reduced the
number of people who have the *slightest* chance of fixing the bug
from "anyone who can run a debugger and read C" to "4-star gurus 
who have all 250,000 lines of code memorized".

if you fire up the postmaster with the -d option, it will spew
all of the backend output onto the postmaster's controlling tty.
seeing what the backend's last dying words were can also help 
us a lot.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

---

From: "David J. Hughes" <[email-masked]>
Date: Wed, 2 Jun 93 17:20:39 -0700

> is what i'm talking about.

I would if I could but I can't so I won't.

In short, there is no core dump in $PGDATA/base/<database>.  The only core
dump is found in the working directory of the libpq based client code
talking to the unfriendly back-end.

> seeing what the backend's last dying words were can also help 

I will forward some debug output and test data/queries etc. to you.

bambi