Re: pltcl.so patch - Mailing list pgsql-hackers

In answer to the question posed at the end of the message below:

Yes, I do get the similar results.

A quick investigation shows that the SPI_freetuptable at the end of
pltcl_SPI_exec is trying to free a tuptable of value 0x82ebe64 (which looks
sensible to me) but which has a memory context of 0x7f7f7f7f (the unallocated
marker).

Briefly following through to check this value shows that as long as I have
CLOBBER_FREED_MEMORY defined, which I presume I do having configured with
--debug, this value is also consistent with the tuptable having been freed
before this faulting invocation.

I haven't looked too closely yet but at a glance I can't see what could be
going wrong with the exception that the tuptable is freed even if zero rows are
returned by SPI_exec. That and I'm not sure what that $T(id) thing is doing in
the SQL submited to pltcl_SPI_exec. Oh 'eck, I've been reading that test
function wrong, it's got a level of nesting.

Unfortunately, I am currently trying to throw together a quick demo of
something at the moment so can't investigate too fully for the next day or so.
If someone wants to pick this up feel free otherwise I'll look into it later.


--
Nigel J. Andrews


On Tue, 24 Sep 2002, Ian Harding wrote to me:

> First, thank you very much for working on this issue.  Pltcl is extremely important to me right now, and this memory
leakis cramping my style a bit.
 
> 
> I applied the patch you sent to my pltcl.c (I am at version 7.2.1, but it seems to apply fine...)  It builds fine,
psqlstarts fine, but my test function still blows up dramatically.
 
> 
> Here is the script I am using:
> 
> drop function memleak();
> create function memleak() returns int as '
> 
>         for {set i 1} {$i < 100} {incr i} {
>                 set sql "select ''foo''"
>                 spi_exec "$sql"
>         }
> 
> 
> ' language 'pltcl';
> 
> drop table testable;
> create table testable (
>         id int,
>         data text);
> 
> insert into testable values (1, 'foobar');
> insert into testable values (2, 'foobar');
> insert into testable values (3, 'foobar');
> insert into testable values (4, 'foobar');
> insert into testable values (5, 'foobar');
> insert into testable values (6, 'foobar');
> 
> drop function memleak(int);
> create function memleak(int) returns int as '
> 
> set sql "select * From testable"
> spi_exec -array T "$sql" {
> 
>         for {set i 1} {$i < 100} {incr i} {
>                 set sql "select * from testable where id = $T(id)"
>                 spi_exec "$sql"
>         }
> }
> ' language 'pltcl';
> 
> Here is what happens:
> 
> bash-2.05# psql -U iharding test < testfunction
> DROP
> CREATE
> ERROR:  table "testable" does not exist
> CREATE
> INSERT 118942676 1
> INSERT 118942677 1
> INSERT 118942678 1
> INSERT 118942679 1
> INSERT 118942680 1
> INSERT 118942681 1
> DROP
> CREATE
> bash-2.05# psql -U iharding test
> Welcome to psql, the PostgreSQL interactive terminal.
> 
> Type:  \copyright for distribution terms
>        \h for help with SQL commands
>        \? for help on internal slash commands
>        \g or terminate with semicolon to execute query
>        \q to quit
> 
> test=# select memleak();
>  memleak
> ---------
>        0
> (1 row)
> 
> test=# select memleak(1);
> server closed the connection unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !#
> 
> 
> Here is the end of the log:
> 
> DEBUG:  server process (pid 1992) was terminated by signal 11
> DEBUG:  terminating any other active server processes
> DEBUG:  all server processes terminated; reinitializing shared memory and semaphores
> IpcMemoryCreate: shmget(key=5432001, size=29769728, 03600) failed: Cannot allocate memory
> 
> This error usually means that PostgreSQL's request for a shared
> ...
>
>
> Do you have similar results?