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

Steven Munroe munroesj at linux.vnet.ibm.com
Fri May 29 13:14:54 PDT 2009

On Wed, 2009-05-27 at 22:47 +0000, Boehm, Hans wrote:
> I don't see a lot of changes directly associated with this code.  GC_remap still uses mprotect instead of mmap to avoid an accidental intervening mapping, at least in the CVS version.  And that seems to be the same in Mono.  It would be helpful to understand exactly why mprotect is failing, i.e. what is mapped at that address when it fails.  Can you find out from /proc/.../maps?  ENOMEM seems particularly uninformative here.
> As Zoltan points out, the Mono source tree has diverged a bit, even aside from using an older version.  But I'm not sure that any of this code has been that well exercised with 64K pages, so the problem may also exist in our versions.
> Hans

This showing up frequently in OpenSIM testing before we disabled

See https://bugzilla.novell.com/show_bug.cgi?id=504411

This includes some examples including /proc/self/maps

Now that the OpenSIM folk have this work around, it will be hard to get
them to switch back for debugging. So what we giving up with this

Also current gc CVS does not show any failures running make check on
SLES11 (with 64K pages) PPC64 system. So it take a larger more complex
test case. If you can think of additional (make check) tests that might
illuminate this problem, I can try to run them. 


More information about the Gc mailing list