Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA13173; Thu, 17 Dec 92 11:35:18 -0800
Message-Id: <9212171935.AA13173@postgres.Berkeley.EDU>
From: <mao@postgres.berkeley.edu>
Subject: Re: Backend crashes--is it me?
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Thu, 17 Dec 92 12:34:08 MST.
             <199212171934.AA00975@kendrick.cse.nau.edu> 
Date: Thu, 17 Dec 92 11:37:48 PST

In message <199212171934.AA00975@kendrick.cse.nau.edu> you write:

> In the previous message I had included a script file and a short
> 'C' program that made the backend either hang or crash.  I was
> worried that the 'C' program was causing the problem but I now
> believe it is not the culprit.
> 
> 1) I reduced the 'C' program to the following and it still
>    crashed the backend:
> 
>       #include "tmp/postgres.h"
>       text *ip_text (tval)
>       text *tval;
>       {
>          return tval;  /* Useless and trivial-- echo */
>       }

the return value from a dynamically-loaded user function, if that value
is pass-by-reference, must be allocated by palloc(), because it's
immediately freed by the backend when it's no longer needed.  this no-op
routine causes postgres to free memory that it believes *you* have
allocated, but which has actually been allocated by *it*, and which
it still needs.  this is causing the core dump.

> /* Now we hang, I believe because of the previous query */
> retrieve (COMPUTER.name, COMPUTER.ip) \p\g

this one will take a little more investigation; we'll file it in the
list of bugs we'll look at for the next release.

					mike