On Jan 6, 2006, at 15:10, <<gnudiff[at]gmail.com>> wrote:
> 0x00002aaaab382873 in malloc_consolidate () from /lib64/libc.so.6
> (gdb) bt
> #0 0x00002aaaab382873 in malloc_consolidate () from /lib64/libc.so.6
> #1 0x00002aaaab383613 in _int_malloc () from /lib64/libc.so.6
> #2 0x00002aaaab383f1a in malloc_check () from /lib64/libc.so.6
> #3 0x000000000048ed4e in debug_xalloc (size=<value optimized out>) at
> pike_memory.c:586
Looks like it's an ordinary malloc() call that dies, and that's a
sure sign of corrupted memory which can be extremely time-consuming
to find. Recompiling Pike with memory debug options or using valgrind
are possible options but perhaps best left for a Pike developer.
I tried valgrind myself on a x86_64 box yesterday but got rather many
warnings about unknown system calls so there's additional work to be
done there before it's really useful. Plus, there's at least one
error report that shows up repeatedly but I don't know if it's a
false positive or real.
Anyway, before we conclude that Pike itself is faulty it would help
to know whether the Pike binary we have available for download
misbehaves in the same way. Understandably you will not have your
custom --with-pgsql switch active but hopefully that won't prevent
you from running a test.
-- Jonas Walldén
<jonasw[at]roxen.com>
|