Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.2/8.9.1) with ESMTP id CAA38367
	for <pgsql-interfaces@postgreSQL.org>;
	Mon, 8 Mar 1999 02:30:09 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA03914;
	Mon, 8 Mar 1999 02:29:36 -0500 (EST)
To: James Thompson <jamest@math.ksu.edu>
cc: PgSQL Interfaces <pgsql-interfaces@postgreSQL.org>
Subject: Re: [INTERFACES] Odd program behaviour 
In-reply-to: Your message of Sun, 7 Mar 1999 17:44:05 -0600 (CST)
	<Pine.GSO.4.05.9903071657210.22421-100000@noether.math.ksu.edu>
Date: Mon, 08 Mar 1999 02:29:36 -0500
Message-ID: <3912.920878176@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

James Thompson <jamest@math.ksu.edu> writes:
> I'm desperate here.  I've got two days invested in this and have not made
> any progress at all.  I'm hoping someone has run into the following and
> might be able to give me a clue.
> Everything works fine when saving data but pulling data from the database
> results in a segfault when using the TCL/TK front end.
> [ segfault is evidently inside malloc ]

A fairly reliable rule is that a segfault inside malloc means your
program has trodden on malloc's data structures that keep track of free
and allocated space in the malloc arena.  Usually this means you have
written off the end of a chunk of malloc'd space.  (Whether this is a
bug in the code that calculated the amount of space to ask for or a bug
in the code using the space is for you to say, of course.)

If you don't have any direct insights into the problem, I'd suggest
building your app with a debugging malloc package that will detect
the corruption as soon as possible.  One I've had good luck with
for apps that don't require huge amounts of space is Electric Fence.
(No URL at hand, but poke around the web and you should find it.)

			regards, tom lane