re: lib/54017: jemalloc deadlock?

[matthew green <mrg%eterna.com.au@localhost>]

Thomas Klausner writes:
>  ld: ../../../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o:(.bss.malloc_conf+0x0): multiple definition of `malloc_conf'; ../../../../memory/build/Unified_cpp_memory_build0.o:(.bss.malloc_conf+0x0): first defined here
>  ld: ../../../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o:(.bss.malloc_message+0x0): multiple definition of `malloc_message'; ../../../../memory/build/Unified_cpp_memory_build0.o:(.bss.malloc_message+0x0): first defined here

christos wrote:
> 1. You should not need to recompile any packages, using the new jemalloc
>    or not should be transparent.
> 2. Turn off pax mprotect if you want to attach to running processes with gdb
> 3. Compile a libc with JEMALLOC_DEBUG defined; most probably it is a
>    memory corruption issue that this might detect.

the multiple definition problem seems to indicate that joerg's
idea of hiding the stats functions by default is going to be
the right solution.

all these crashes makes me think that new jemalloc should be
reverted in -current and delayed until netbsd-9 happens, so
that we have heaps of time to find all the issues, rather
than shipping a damaged or delayed netbsd-9.


.mrg.