Alvaro Herrera <[EMAIL PROTECTED]> writes: > Osprey is a NetBSD running on m68k
Yeah, it's been failing consistently on the 8.2 branch for a while, but not either 8.1 or HEAD, which is awfully strange. > Program terminated with signal 11, Segmentation fault. > #0 0x001f74d6 in AllocSetAlloc (context=0x307d10, size=16777212) at > aset.c:546 > 546 if (set->blocks != NULL) > I don't understand how can this happen, given that "set" cannot be NULL > at this point. I talked to Remi about this last month, and we concluded that the core dump is probably really at the line just prior, where it's trying to stick a marker at the end of the used space: ((char *) AllocChunkGetPointer(chunk))[size] = 0x7E; But neither of us could see how that could happen unless malloc is outright broken. Remi did some gdb'ing that seemed to indicate that malloc had failed to provide a block as large as it claimed: : =?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. and it kinda tailed off there ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend