From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27057 invoked by alias); 9 Feb 2005 05:38:38 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 27033 invoked by uid 48); 9 Feb 2005 05:38:36 -0000 Date: Wed, 09 Feb 2005 09:20:00 -0000 Message-ID: <20050209053836.27032.qmail@sourceware.org> From: "Hans dot Boehm at hp dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20050208143717.19823.matz@suse.de> References: <20050208143717.19823.matz@suse.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/19823] java fails with non-executable memory X-Bugzilla-Reason: CC X-SW-Source: 2005-q1/txt/msg00291.txt.bz2 List-Id: ------- Additional Comments From Hans dot Boehm at hp dot com 2005-02-09 05:38 ------- I believe that the GC alters permissions on the heap only if either - It is running in incremental mode, or - It is built with USE_MMAP, and thus uses mmap to allocate the heap. I think we talked about always doing the latter, but we don't. Thus I think the heap is allocated with sbrk. If the kernel no longer gives execute permission for sbrk memory, then that would propagate through to the Java heap. That would presunably break libffi. It should be possible to confirm a lot of this with strace. I think the collector is configured to disable execute permission whenever it resets permissions. Thus if we used mmap, libffi would presumably break consistently everywhere it tries to put trampolines in the heap. (It doesn't need trampolines on all platforms.) If all of this is correct, then building the collector with USE_MMAP, and telling it to enable execute permission, might be a work-around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823