------- Comment #3 from fexx at fexx dot org 2006-02-21 14:52 -------
I belive this is another bug than 12475. (I'm using libgcj come with gcc 3.4.5
distribution.)
PR 12475 stated that, when an Exception was initialized, a constructor
gnu.gcj.runtime.StackTrace(int) was indirectly invoked, and the native
memory allocated and set to StackTrace.addrs in
StackTrace.fillInStackTrace(int,int) leaked. Hence, the fix to 12475
freed the (leaked) native memory in gnu.gcj.finalize().
This one, PR 26351, is a problem regarding some use of
gnu.gcj.runtime.StackTrace.classAt(int). It causes two (or more)
invokation of StackTrace.fillInStackTrace(int,int) against a same
StackTrace object, once from its constructor, and once more from
classAt(int). Every invokation of fillInStackTrace(int,int) allocates
a new native memory through _Jv_Malloc() and store it in addrs. The
second invokation silently discards the native memory allocated during
the first, causing a leak. _Jv_Free in finalize() doesn't help.
(Please note that the macro GET_FRAME used in the native method
StackTrace.classAt(int) *may* invoke fillInStackTrace *when* N is
larger than expected.)
There may be another execution paths, but calling
java.util.ResourceBundle.getBundle(String) was the easiest case that I could
find.
--
fexx at fexx dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
