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

Stefan Kaltenbrunner <stefan@kaltenbrunner.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