Bug 678 - mono runtime crashes with mmap(...PROT_NONE...)
Summary: mono runtime crashes with mmap(...PROT_NONE...)
Status: RESOLVED DUPLICATE of bug 6216
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2011-09-08 12:11 UTC by Micha
Modified: 2013-04-21 15:39 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Micha 2011-09-08 12:11:08 UTC
Hi all,

I have a problem with the mono runtime.
I'am using debian linux sqeeze. 
uname -a: Linux 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux
It is a 64 Bit System with Intel 4Core and 8GB RAM.
I'am using mono 2.11 beta.

After the program has started a little time later the mono-runtime crashes 
with the following error:

GC_unmap() mmap(...PROT_NONE...) failed input: 0x7f203c777000 result: 0xffffffffffffffff, errno: 12, ernostr: Cannot allocate memory


  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) <IL 0x0000e, 0xffffffff>
  at System.Array.Resize<double> (double[]&,int) [0x0002a] in /opt/derixx/mono/src/mono/mcs/class/corlib/System/Array.cs:2237
  at System.Collections.Generic.List`1<double>.set_Capacity (int) [0x00012] in /opt/derixx/mono/src/mono/mcs/class/corlib/System.Collections.Generic/List.cs:621
  at System.Collections.Generic.List`1<double>.GrowIfNeeded (int) [0x00017] in /opt/derixx/mono/src/mono/mcs/class/corlib/System.Collections.Generic/List.cs:98
  at System.Collections.Generic.List`1<double>.Add (double) [0x00013] in /opt/derixx/mono/src/mono/mcs/class/corlib/System.Collections.Generic/List.cs:89
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <IL 0x0005c, 0xffffffff>

Native stacktrace:

	mono() [0x492cd6]
	/lib/libpthread.so.0(+0xef60) [0x7f5b3a12ef60]
	/lib/libc.so.6(gsignal+0x35) [0x7f5b39df1165]
	/lib/libc.so.6(abort+0x180) [0x7f5b39df3f70]
	mono() [0x5dfbca]
	mono() [0x5e8918]
	mono() [0x5e6683]
	mono() [0x5eda2f]
	mono() [0x5ed0bf]
	mono() [0x5ee16d]
	mono() [0x5e523d]
	mono() [0x5e5604]
	mono() [0x5e57cb]
	mono() [0x5ea949]
	mono(mono_array_new_specific+0xba) [0x51da0a]

Debug info from gdb:

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.

The original error message is: mmap(...PROT_NONE...) failed

I have added additional Debug Information with the following code:

 /* We immediately remap it to prevent an intervening mmap from    */
 /* accidentally grabbing the same address space.                  */
   void * result;
   void* startAddr;
   startAddr = start_addr;
   result = mmap(start_addr, len, PROT_NONE,
                 MAP_PRIVATE | MAP_FIXED | OPT_MAP_ANON,
                 zero_fd, 0/* offset */);
   if (result != (void *)start_addr)
       char line[256];
       sprintf(line, "GC_unmap() mmap(...PROT_NONE...) failed input: %p result: %p, errno: %i, ernostr: %s\n", startAddr, result, errno, strerror(errno));
      // ABORT("GC_unmap() mmap(...PROT_NONE...) failed");
 GC_unmapped_bytes += len;
 The Debug informations are done in mon/libgc/os_dep.c near line 2033-2037
 in function GC_unmap();
 The program uses nearly 2.7-3.0 GB RAM and than it crashes. IMHO it should be able to use more
 memory. No other application is running in that time.
 Are there known limitations for using memory in mono under linux?
 Unfortanly it was until now impossible to make a short testcase. I don't know
 which part of the application is causing this.
Comment 1 Zoltan Varga 2011-09-08 20:29:19 UTC
As a workaround, you try commenting out these lines in configure.in:

                if test "x$disable_munmap" != "xyes"; then
                        CPPFLAGS="$CPPFLAGS -DUSE_MUNMAP"

(there are lots of them) and rebuilding.
Comment 2 Micha 2011-09-09 10:13:06 UTC
Hi Zoltan,

thanks for your reply. I have uncommented the lines that you mentioned in the file mono/configure.in.

Its still crashes with the same error: mmap(...PROT_NONE...) failed

In the function in which the crash occurs (GC_unmap()) the function mmap is used instead of munmap.

Have you another idea how I can find a workaround?
Comment 3 Zoltan Varga 2011-09-09 10:29:28 UTC
-DUSE_MUNMAP means the GC will try to unmap memory when the size of the GC heap can be decreased, so removing it should fix this issue. No idea why this doesn't happen. You might want to try replacing '-DUSE_MMAP' with '' in configure.in too, maybe that will help.
Comment 4 Micha 2011-09-09 11:14:42 UTC

I have done the following changes in mono/configure.in: line 213-216

#      if test "x$disable_munmap" != "xyes"; then                        ^
#          CPPFLAGS="$CPPFLAGS -DUSE_MUNMAP"                          remove
#      fi                                                            -DUSE_MMAP

I removed the Flag -DUSE_MMAP in the line with the CPPFLAGS
and uncomment the following three lines.

After starting the program with this version the crash still remains.
Comment 5 Rodrigo Kumpera 2012-04-22 23:10:34 UTC
Is libgc been built with -DUSE_UNMAP or not? use make -V=1 to check it.
Comment 6 Zoltan Varga 2013-04-21 15:39:17 UTC
Marking as a dup.

*** This bug has been marked as a duplicate of bug 6216 ***