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 ?


Rémi Zara

Le 11 mars 07 à 08:32, Tom Lane a écrit :

I wrote:
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to