Thread: 7.4RC1 et al: cannot find block containing chunk

7.4RC1 et al: cannot find block containing chunk

From
greimel@ing.iac.es (Robert Greimel)
Date:
============================================================================
                        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:

>psql database
=# SELECT id,deg2ra(ra),deg2dec(dec),frames FROM Fields;
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
>psql database
=# SELECT id,ra,deg2dec(dec),frames FROM Fields;
  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
>psql database
=# SELECT deg2ra(300);
    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:
>psql database
=# LOAD '/some/path/coord.so';
=# 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):
>psql database
=# SELECT id,deg2dec(dec),deg2ra(ra),frames FROM Fields;
  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)
>psql database
=# SELECT id,deg2dec(dec),deg2ra(ra),frames FROM Fields;
ERROR:  could not find block containing chunk 0x82eca00

postmaster (-d 3 and -d 4)
>psql database
=# SELECT id,deg2dec(dec),deg2ra(ra),frames FROM Fields;
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)
>psql database
=# SELECT deg2ra(300);
    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)
>psql database
=# SELECT deg2ra(300);
    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)
>psql database
=# LOAD '/some/path/coord.so';
=# 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

>psql database
=# SELECT id,deg2dec(dec),deg2ra(ra),frames FROM Fields;
  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.

Re: 7.4RC1 et al: cannot find block containing chunk

From
Peter Eisentraut
Date:
Robert Greimel writes:

> 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:
>
> >psql database
> =# SELECT id,deg2ra(ra),deg2dec(dec),frames FROM Fields;
> ERROR:  AllocSetFree: cannot find block containing chunk 0x83a5300

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

--
Peter Eisentraut   peter_e@gmx.net

Re: 7.4RC1 et al: cannot find block containing chunk

From
Tom Lane
Date:
greimel@ing.iac.es (Robert Greimel) writes:
> 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

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

Re: 7.4RC1 et al: cannot find block containing chunk

From
greimel@ing.iac.es (Robert Greimel)
Date:
>Apparently, the implementation of that function contains a bug in the
>memory handling.

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

Robert