re: lib/54017: jemalloc deadlock?

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

The following reply was made to PR lib/54017; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost, christos%netbsd.org@localhost
Subject: re: lib/54017: jemalloc deadlock?
Date: Sun, 10 Mar 2019 11:05:00 +1100

 Thomas Klausner writes:
 >  ld: ../../../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o:(.bss.ma=
 lloc_conf+0x0): multiple definition of `malloc_conf'; ../../../../memory/b=
 uild/Unified_cpp_memory_build0.o:(.bss.malloc_conf+0x0): first defined her=
 e
 >  ld: ../../../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o:(.bss.ma=
 lloc_message+0x0): multiple definition of `malloc_message'; ../../../../me=
 mory/build/Unified_cpp_memory_build0.o:(.bss.malloc_message+0x0): first de=
 fined 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.