From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rémi Zara <remi_zara(at)mac(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why is "osprey" dumping core in REL8_2 branch? |
Date: | 2007-03-11 07:32:31 |
Message-ID: | 16600.1173598351@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> =?ISO-8859-1?Q?R=E9mi_Zara?= <remi_zara(at)mac(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rémi Zara | 2007-03-11 09:59:47 | Re: Why is "osprey" dumping core in REL8_2 branch? |
Previous Message | Alvaro Herrera | 2007-03-11 05:24:15 | Re: Race condition in pg_database_size() |