Stefan Kaltenbrunner <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
