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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)
Date: 2005-06-18 19:30:15
Message-ID: 1320.1119123015@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-06-18 19:31:06 Checkpointing problem with new buffer mgr.
Previous Message Stefan Kaltenbrunner 2005-06-18 19:24:40 Re: hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)

Browse pgsql-patches by date

  From Date Subject
Next Message Michael Fuhr 2005-06-18 20:00:14 Typo in pl_funcs.c comment
Previous Message Stefan Kaltenbrunner 2005-06-18 19:24:40 Re: hashtable crash (was Re: [PATCHES] Post-mortem: final 2PC patch)