Illegal Package-Private Accesses in 3.4

Bryce McKinlay bryce@mckinlay.net.nz
Mon Aug 11 06:45:00 GMT 2003


On Monday, Aug 11, 2003, at 09:23 Pacific/Auckland, Mark Wielaard wrote:

> Hi (discussion moved from java to java-patches),
>
> On Wed, 2003-07-09 at 21:35, Ranjit Mathew wrote:
>>     I applied my package-private access checking patch/kludge to
>> the 3.4 snapshot from 2007-07-02 and found that some of the
>> issues I had reported earlier in 3.3 have been resolved while
>> a new one has been added.
>>
>> The issues still present are:
>>
>>  2. java.lang.VMThrowable illegally calls "stackTraceAddrs( )"
>>     in gnu.gcj.runtime.StackTrace.
>
> It seems to me that the best thing to do is to move StackTrace to the
> java.lang package and make it package private to prevent any 'illegal'
> access to this class by user code.

Lets have a look at where stackTraceAddrs() is being used in 
VMThrowable:

	NameFinder nameFinder = new NameFinder();
	result = nameFinder.lookup(t, trace.stackTraceAddrs(),
				   trace.length());

Since NameFinder and StackTrace are both in the same package, wouldn't 
a simpler solution be to pass "trace" itself and have NameFinder call 
the stackTraceAddrs?

It would be cleaner to keep these things in the same package wherever 
possible. If we're worried about user code calling NameFinder being a 
security risk, we could add a security check to its constructor.

BTW, I notice some evil use of RawData & _Jv_Malloc in StackTrace. 
Specifically I don't see 'addrs' getting freed anywhere! I think its 
better to avoid RawData wherever possible, and use byte[] instead. And 
maybe we should ban _Jv_Malloc from libgcj to enforce this ;-)

Regards

Bryce.



More information about the Java-patches mailing list