This is the mail archive of the
mailing list for the Java project.
Re: FYI Patch: Fix memory leak PR 12475
- From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- To: Andrew Haley <aph at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: Fri, 3 Oct 2003 12:55:16 +1200
- Subject: Re: FYI Patch: Fix memory leak PR 12475
On Thursday, Oct 2, 2003, at 22:01 Pacific/Auckland, Andrew Haley wrote:
Bryce McKinlay writes:
This is a temporary hack to fix PR 12475. Eventually I plan to
re-factor the stack trace stuff and get rid of the malloc.
There are a few issues to think about. Firstly, it would be very nice
to do away with the dependency on external programs altogether, but as
has been discussed here we'd lose line numbers in stack traces.
Alternative implementations, perhaps.
Yes - the source file/line numbers are only required for a
Throwable.printStackTrace() call. We should, of course, never be
calling external programs for other uses of stack tracing, such as
Thirdly, the factoring of stack traces is already weird because of
Classpath compatibility requirements.
I don't think there is anything wrong with the VMThrowable interface.
It is our implementation of it that is the problem ;-)
Fourthly, there are some very tricky security issues. In particular,
access to raw stack traces needs to be restricted to a few places. I
intend to do this by carefully using native code and friend access.
My basic idea is to put the common stack-trace infrastructure - ie the
parts used for both exceptions and security - in a stacktrace.cc or
something similar. natVMThrowable will use that and StackTrace.java etc
will go away. NameFinder will remain, for now, but only to do
source/line info lookups. Making it native means no security problem,
alleviates the passing-around-RawData's mess, and makes it more
convenient to use because the places this is used are native anyway.
Fifthly, there are some tricky efficiency requirements.
Definitely. For calling-classloader checking, for example, we only want
to walk the stack as far as is needed to find the caller. Also, we want
to avoid allocations while doing security checks.