[Mono-list] Segmentation fault with "GC_ENABLE_INCREMENTAL"

Tom Fransen t.fransen@mailned.nl
Tue, 22 Jul 2003 06:10:30 +0100


below the reply I got on a similar question:

 | On a Linux system
 | (and on many others) turning on incremental collection will cause the
 | heap to be write protected.  The collector will handle the resulting
 | write faults, unless they occur inside a system call.  Thus you will
 | need to be careful with, and preferably avoid, system calls that write
 | directly to the garbage-collected heap.  (If the application is
 | single-threaded, or nearly single-threaded, you can also wrap the system
 | calls with some routines provided by the collector.  In some cases, it's
 | also OK to have system calls write to objects allocated with
 | GC_MALLOC_ATOMIC.  But this has turned out to be enough of an issue that
 | I believe there are relatively few clients for the incremental
 | collector.)

In other words, turning on incremental collection would require
carefully vetting the mono source code to make sure that there are no
calls to system calls that might write directly to memory allocated
with GC_malloc() and friends.  There might also be some nasty
interactions with the C interface (PlatformInvoke etc.)

-----Original Message-----
From: mono-list-admin@lists.ximian.com
[mailto:mono-list-admin@lists.ximian.com]On Behalf Of Okehee Goh
Sent: Wednesday, July 16, 2003 11:09 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Segmentation fault with "GC_ENABLE_INCREMENTAL"

 I run Mono-0.25 with "GC_ENABLE_INCREMENTAL" to enable an incremental GC.
 But it just gave a segmentation fault.
 One of documents regarding Boehm's GC says that the incremental GC can
cause "unintended system call failure."
 (Refer to the following..)
 Is there anybody who didn't encounter this problem? My system is Linux
kernel 2.4 and i686.

 GC_ENABLE_INCREMENTAL - Turn on incremental collection at startup. Note
depending on platform and collector configuration, this
may involve write protecting pieces of the heap to
track modifications. These pieces may include pointerfree
objects or not. Although this is intended to be
transparent, it may cause unintended system call failures.
Use with caution.

 Any suggestion will be appreciated.



Mono-list maillist  -  Mono-list@lists.ximian.com