From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13701 invoked by alias); 1 Feb 2006 16:52:49 -0000 Received: (qmail 13640 invoked by uid 48); 1 Feb 2006 16:52:48 -0000 Date: Wed, 01 Feb 2006 16:52:00 -0000 Message-ID: <20060201165248.13639.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "thebohemian at gmx dot net" 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 X-SW-Source: 2006-q1/txt/msg00092.txt.bz2 List-Id: ------- Comment #2 from thebohemian at gmx dot net 2006-02-01 16:52 ------- Added aph to get some ideas on how to solve this. Some ideas: The code that uses the ffi structure is so complicated because it is neccessary to prepare a call that takes one argument (a class name). I plan to put setup code into a separate method because I saw another location where this behavior is needed (link.cc around line 1203). Furthermore I was told that the ffi functions are not implemented on certain architectures (eg ARM) and would cause compilation problems. The new method would take this into account and provide a path with degraded functionality: Do not create any ffi stuff and do not provide the name of the missing class as argument. I am a bit clueless on how to solve the memory leak thing and appreciate ideas & pointers. -- thebohemian at gmx dot net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aph at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063