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