[Gc] GC_remap fails with ENOMEM on Linux with large (64K) pages.

Steven Munroe munroesj at linux.vnet.ibm.com
Tue May 26 15:46:18 PDT 2009


We are trying to use mono 64-bit on SLES11 PowerPC. We are seeing lots
of failures of the form:

Mprotect failed at 0x40002790000 (length 131072) with errno 12

Thread 1 (Thread 0x40000510000 (LWP 14909)):
#0  0x0000040000205b90 in .__libc_read () from /lib64/power6x/libpthread.so.0
#1  0x0000000010082300 in mono_handle_native_sigsegv (
    signal=<value optimized out>, ctx=<value optimized out>)
    at mini-exceptions.c:1480
#2  0x000000001001b0cc in sigabrt_signal_handler (
    _dummy=<value optimized out>, info=<value optimized out>, 
    context=0xfffffa1bbc0) at mini.c:4286
#3  <signal handler called>
#4  0x0000040000366630 in .raise () from /lib64/power6x/libc.so.6
#5  0x0000040000368300 in .abort () from /lib64/power6x/libc.so.6
#6  0x00000000101d55a8 in GC_abort (
    msg=0x10274500 "Mprotect remapping failed") at misc.c:1074
#7  0x00000000101d1c4c in GC_remap (start=0x40002781000 "", bytes=221184)
    at os_dep.c:1965
#8  0x00000000101c4b98 in GC_allochblk_nth (sz=5, kind=0, flags=0 '\0', n=34)
    at allchblk.c:730
#9  0x00000000101c4404 in GC_allochblk (sz=5, kind=0, flags=0)
    at allchblk.c:561
#10 0x00000000101cba24 in GC_new_hblk (sz=5, kind=0) at new_hblk.c:253
#11 0x00000000101c9dd8 in GC_allocobj (sz=5, kind=0) at alloc.c:1116
#12 0x00000000101c2304 in GC_generic_malloc_inner (lb=34, k=0) at malloc.c:136
#13 0x00000000101c2508 in GC_generic_malloc (lb=34, k=0) at malloc.c:192
#14 0x00000000101c2864 in GC_malloc_atomic (lb=34) at malloc.c:262
#15 0x00000000100de458 in mono_array_new_specific (vtable=0x10394cc0, n=1)
    at object.c:3536

This problem goes away if we remove -DUSE_MMAP -DUSE_MUNMAP from this line in mono's configure.in:
               CPPFLAGS="$CPPFLAGS -DGC_LINUX_THREADS -D_GNU_SOURCE
-D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP"

So there seems to be problem in libgc which specific to the use of MMAP
storage with 64K (non-4K) pages as the mprotect is trying to change the
protections over a gap in the process map.

So I was wondering if this was a known problem with libgc on large page
platforms and is there was a fix in the newer versions of libgc?

Thanks



More information about the Gc mailing list