Re: hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> Tom Lane wrote:
>> dynahash.c thinks it should always copy 255 bytes of key, since that's
>> what it was told the key size was ... but in this case the supplied
>> search key has been allocated very close to the end of the process's
>> memory, and there are not 255 bytes before the end of memory.

> aaah - this description rings a bell ...

> OpenBSD has some very useful features for configuration of malloc() -
> and on this particular box it has:

> G ``Guard''. Enable guard pages and chunk randomization. Each
> page size or larger allocation is followed by a guard page that
> will cause a segmentation fault upon any access. Smaller than
> page size chunks are returned in a random order.

> and indeed - enabling "G" on another (x86) OpenBSD box of mine causes
> make check to die there too ....

Cool. Once I get this bug fixed, the people running openbsd build farm
machines probably should turn that on as standard practice ... we've
found bugs of this ilk several times before, and I would not be
surprised if there are more.

The palloc mechanism probably does quite a lot to mask this type of
error, since it aggregates small chunk requests into large malloc
chunks. If you read past the end of a palloc'd chunk it's quite
unlikely that you'll see a problem. I wonder if it is worth having
a debug-build option that defeats that somehow ...

regards, tom lane