"PostgreSQL Bugs List" <pgsql-bugs@postgresql.org> writes:
> It seems that MnoGoSearch 3.2.17 is capable of crashing postgresql 7.4.2
> repeatedly every once in a while on Amd Athlon/Fedora Core 2.
Can you provide a self-contained test case for this?
> The gdb trace:
> (gdb) where
> #0 0x006af8b3 in memcpy () from /lib/libc.so.6
> #1 0x081c7f48 in varstr_cmp (arg1=0x83c8f74 "51", len1=2, arg2=0x1f50e054
> "..", len2=33685512) at varlena.c:866
> #2 0x081c8071 in text_cmp (arg1=0x2020008, arg2=0x522017) at varlena.c:905
> #3 0x081c8398 in bttextcmp (fcinfo=0xbfe750e0) at varlena.c:1021
> #4 0x081eb96d in FunctionCall2 (flinfo=0x1d400020, arg1=33685512,
> arg2=33685512) at fmgr.c:993
> #5 0x08089351 in _bt_compare (rel=0x2020008, keysz=2, scankey=0x83c8fa8,
> page=0x522017 "", offnum=32)
> at nbtsearch.c:351
This isn't super helpful since some of the passed arguments are
evidently clobbered already; it's hard to tell which values to trust.
I was initially going to say that the ridiculous len2 argument to
varstr_cmp suggests corrupt data, but seeing that the same value appears
in several places on the trace (some in hex), I'm not sure if it's real
or if gdb is confused. You might try rebuilding the backend with a
lower optimization level so as to get a more reliable stack trace.
Note that what is happening here is a comparison between an index key
value being inserted and a key value already in the index. So one
possible explanation is that the previously stored value is corrupt
due to memory or disk problems. Have you run any hardware diagnostics?
Can you reproduce the problem on another machine?
regards, tom lane
