Hi,
I know the answer :)
I tried to find the patch that caused the failure, and when doing so,
rechecking a build which had succeeded now failed. So this was an
environment problem.
The solution was to change the ulimit for data segment size. I hadn't
thought of that because I had originally enabled this conf because pg
would not otherwise BUILD...
Doesn't this mean that there is some place where the return value of
malloc is not checked for null ?
Regards,
Rémi Zara
Le 11 mars 07 à 08:32, Tom Lane a écrit :
> I wrote:
>> Rémi Zara <remi_zara@mac.com> writes:
>>> (gdb) info locals
>>> block = 0x4395000
>>> chunk = 0x4395010
>>> priorfree = 0x5395020
>>> chunk_size = 16777216
>>> blksize = 70864912
>>> (gdb) p *block
>>> $5 = {aset = 0x306d10, next = 0x0, freeptr = 0x5395020 <Address
>>> 0x5395020 out of bounds>, endptr = 0x5395020 <Address 0x5395020
>>> out of bounds>}
>
>> Well, that's pretty dang interesting. If the end of the block is
>> indeed
>> out of bounds as gdb claims, that'd explain why it crashes right here
>> (actually the crash would be induced by the preceding line of code,
>> where it tries to store a marker byte). But how can that be, unless
>> malloc is completely broken? And if it is, why's it only
>> affecting the
>> 8.2 branch? I'm confused.
>
> Whoa ... osprey just went green in the 8.2 branch, following what is
> most surely an unrelated patch in vacuum.c. Can anyone explain that?
> I distrust gift horses ...
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
>
