Re: FYI Patch: Fix memory leak PR 12475

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

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 
security checks.

> 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.

Regards

Bryce.