Re: BUG #3752: query yields "could not find block containing chunk", then server crashes

Just forwarding this info along as Zdenek requested...

Turns out this problem is not a bug in pg8.3, it was a problem with our
custom data type. I have since dropped the custom data type and am now
using standard pg float4 arrays. Did the dump and restore, and our app
works just fine, no crash when the query is run.

BTW- PG8.3 seriously rocks! We've got some large tables that had very
poor performance in PG8.1... things are really snappy now, HOT usage
really helps our app (as shown by the handy pg_stat_all_tables).

Mike

Zdenek Kotala wrote:
> Mike Charnoky wrote:
>> It seems this problem has to do with a custom data type we are using. I
>> am working on eliminating this custom data type, as it is becoming too
>> much of a pain to support (it is basically float4[]). If the problem
>> persists after the data type conversion, I will follow up. Otherwise, I
>> think this was an error in our custom type code (maybe corruption during
>> dump/reload)
>
> Thanks for update.
>
>> Would the stack trace still be useful? Where would I find the dump
>> file? I didn't see anything...
>
> If you are sure, that it is in your data type implementation then
> probably not. You can find core file usually in postgres data directory
> if you have core file generation enabled by ulimit command. You can get
> stack trace by gdb.
>
> Zdenek
>
>>
>> Mike
>>
>> Zdenek Kotala wrote:
>>> Michael Charnoky wrote:
>>>
>>> <snip>
>>>> 2007-11-15 15:38:03.880 PST: ERROR: could not find block containing
>>>> chunk
>>>> 0x902fb98
>>> This message appears in AllocSetFree or AllocSetRealloc function in
>>> aset.c source. In both function it means that defined context does not
>>> contain memory block. By my opinion there should be two more probable
>>> scenarios:
>>>
>>> 1) memory block does not exist -> for AllocSetFree it means e.g. double
>>> free or for AllocSetRealloc it means that somebody want to realloc
>>> memory which was already freed.
>>>
>>> 2) memory is still allocated but in different context. However, palloc
>>> and pfree should control it.
>>>
>>>
>>> By my opinion it is double free problem, but without stack trace or
>>> reproduction scenario it is difficult to find it.
>>>
>>> Zdenek
>