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

2005-06-18 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Can you please look at > http://www.openbsd.org/cgi-bin/man.cgi?query=malloc.conf&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html > > and tell us which ones you would like turned on? Stefan suggests A F and > G might be useful. Not

Re: [HACKERS] hashtable crash (was Re: [PATCHES] Post-mortem: final

2005-06-18 Thread Andrew Dunstan
Tom Lane wrote: Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: 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 a

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

2005-06-18 Thread Tom Lane
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

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

2005-06-18 Thread Stefan Kaltenbrunner
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. aaa

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

2005-06-18 Thread Tom Lane
Oh-ho, I see it: (gdb) bt #0 0x4489fba4 in memcpy () from /usr/lib/libc.so.34.2 #1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90, action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653 #2 0x003434f0 in pg_tzset (name=0xa5ff90 "PST8PDT") at pgtz.c:1039 #3 0x