================================================== ==========================
POSTGRESQL BUG REPORT TEMPLATE
================================================== ==========================


Your name : Robert Greimel
Your email address : greimel ( at ) ing ( dot ) iac ( dot ) es


System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel Pentium
AMD Athlon

Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.18 ELF (RedHat-8)
Linux 2.4.22 ELF (homegrown)

PostgreSQL version (example: PostgreSQL-7.3): PostgreSQL-7.4RC1
PostgreSQL-7.2.3
PostgreSQL-7.2.2

Compiler used (example: gcc 2.95.2) : gcc 3.2


Please enter a FULL description of your problem:
------------------------------------------------

7.2.2 and RedHat 8
===================
using PostgreSQL-7.2.2 and several user defined C function - dynamically loaded
from one .so file - I (sometimes) see the following error message doing the
following query:

ERROR: AllocSetFree: cannot find block containing chunk 0x83a5300

Here deg2dec and deg2ra are user functions defined as
CREATE FUNCTION deg2dec(float4) RETURNS text AS '/some/path/coord.so','deg2dec_float4' LANGUAGE C WITH (isStrict);
CREATE FUNCTION deg2dec(float8) RETURNS text AS '/some/path/coord.so','deg2dec_float8' LANGUAGE C WITH (isStrict);
CREATE FUNCTION deg2ra(float4) RETURNS text AS '/some/path/coord.so','deg2ra_float4' LANGUAGE C WITH (isStrict);
CREATE FUNCTION deg2ra(float8) RETURNS text AS '/some/path/coord.so','deg2ra_float8' LANGUAGE C WITH (isStrict);

and ra and dec are defined as REAL in table Fields.

The query
id | ra | deg2dec | frames
-------+---------+---------------+--------
3706 | 99.4405 | -04:16:00.001 | {0}
....
(deg2ra function removed) works. There is only a minute difference in the
code for deg2dec and deg2ra, so I am fairly certain that its not a programming
error on my part - although this is my first go on extending Postgres.

Calling (in a new psql session) the deg2ra function once before the query
deg2ra
--------------
20:00:00.000
(1 row)
=# SELECT id,deg2ra(ra),deg2dec(dec),frames FROM Fields;
id | deg2ra | deg2dec | frames
-------+--------------+---------------+--------
3706 | 06:37:45.720 | -04:16:00.001 | {0}
....
makes the query work !!!

7.2.3 and RedHat 8
==================
using PostgreSQL-7.2.3 the same error is produced as in 7.2.2 .

However, the workaround of calling deg2ra before doing the query no longer
works. The single "SELECT deg2ra(300)" works - and I have never seen it fail -
but the table query afterwards produces the AllocSetFree error.

However, explicitly loading the dynamic code makes the query work again:
=# SELECT id,deg2ra(ra),deg2dec(dec),frames FROM Fields;
id | deg2ra | deg2dec | frames
-------+--------------+---------------+--------
3706 | 06:37:45.720 | -04:16:00.001 | {0}
....
works !!!

Interestingly, reversing the columns that call the functions also makes the
query work (this does not need an explicit LOAD or single SELECT before):
id | deg2dec | deg2ra | frames
-------+---------------+--------------+--------
3706 | -04:16:00.001 | 06:37:45.720 | {0}
....
works !!!

7.4RC1 and my own homegrown Linux
=================================
PostgreSQL-7.4RC1 still has the problem, but in a slightly different form.
The error is now

ERROR: could not find block containing chunk 0x82eff00

This time I also experimented with debug levels. For a straight query there
was a slight difference in the reported error for the different debug levels,
but none worked:

postmaster (without debug, -d 1 and -d 2)
ERROR: could not find block containing chunk 0x82eca00

postmaster (-d 3 and -d 4)
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.
!> \q

Doing the single SELECT before the query gives also different results depending
on debug level - it works for high debug levels but not for low:

postmaster (without debug, -d 1 and -d 2)
deg2ra
--------------
20:00:00.000
(1 row)

=# SELECT id,deg2dec(dec),deg2ra(ra),frames FROM Fields;
ERROR: could not find block containing chunk 0x82eca00


postmaster (-d 3 and -d 4)
deg2ra
--------------
20:00:00.000
(1 row)

=# SELECT id,deg2dec(dec),deg2ra(ra),frames FROM Fields;
id | deg2ra | deg2dec | frames
-------+--------------+---------------+--------
3706 | 06:37:45.720 | -04:16:00.001 | {0}
....


Doing the LOAD of the dynamic module explicitly worked for all debug levels.

postmaster (without debug, -d 1, -d 2, -d 3 and -d 4)
=# SELECT id,deg2ra(ra),deg2dec(dec),frames FROM Fields;
id | deg2ra | deg2dec | frames
-------+--------------+---------------+--------
3706 | 06:37:45.720 | -04:16:00.001 | {0}
....

Reversing the column order worked for all debug levels

id | deg2dec | deg2ra | frames
-------+---------------+--------------+--------
3706 | -04:16:00.001 | 06:37:45.720 | {0}
....

Hope this is useful in tracking down the bug - if you need more information,
please email me.

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

see above.



If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

see above for workarounds.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Robert Greimel writes:

Apparently, the implementation of that function contains a bug in the
memory handling.

--
Peter Eisentraut peter_e (AT) gmx (DOT) net


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

greimel (AT) ing (DOT) iac.es (Robert Greimel) writes:
This indicates that somebody is pfree'ing a pointer that did not come
from palloc, or possibly pfree'ing the same pointer twice. It could be
that the bad pfree is the indirect result of an earlier memory clobber,
too.

Given that you are using user-defined C functions it seems highly likely
that the bug is in your code and not Postgres. If you can reproduce the
bug without any of your own C functions having been executed, please
send along a script that does it ...


regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

oops - found it. String allocation was 1 byte short. Thanks.

Robert

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster