Re: [HACKERS] Why is "osprey" dumping core in REL8_2 branch?

[Rémi Zara]

Hi,

I know the answer :)







Regards,

Rémi Zara


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

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 ?

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

8.2 branch?  I'm confused.

malloc is completely broken? And if it is, why's it only affecting the

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


TIP 1: if posting/reading through Usenet, please send an appropriate

       message can get through to the mailing list cleanly

---------------------------(end of broadcast)--------------------------- subscribe-nomail command to [EMAIL PROTECTED] so that your

smime.p7s
Description: S/MIME cryptographic signature