Re: Why is "osprey" dumping core in REL8_2 branch?
I wrote:
=?ISO-8859-1?Q?R=E9mi_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
Import Notes
Reply to msg id not found: 26878.1168124966@sss.pgh.pa.usReference msg id not found: 16015.1168011694@sss.pgh.pa.usReference msg id not found: 2AA49D05-708E-4C24-8F3D-52118D3B0EA2@mac.comReference msg id not found: 29339.1168025572@sss.pgh.pa.usReference msg id not found: 775175CF-DF11-4219-93F9-196222531A5E@mac.comReference msg id not found: 4034.1168104200@sss.pgh.pa.usReference msg id not found: 75846058-AF79-4FE0-88CA-D6BBEEE27A71@mac.comReference msg id not found: 26878.1168124966@sss.pgh.pa.us
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 :
Show quoted text
I wrote:
=?ISO-8859-1?Q?R=E9mi_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
Attachments:
=?ISO-8859-1?Q?R=E9mi_Zara?= <remi_zara@mac.com> writes:
The solution was to change the ulimit for data segment size.
Oh really ...
Doesn't this mean that there is some place where the return value of
malloc is not checked for null ?
You can see for yourself that the value *is* checked in the routine
that's at issue --- see line 520 in 8.2's aset.c. Also the gdb'ing
you did showed that a nonzero value had been returned.
I think what you're looking at is a platform-specific bug in malloc().
regards, tom lane