Re: GCJ 3.3 LEAKS Throwable & Derived Classes

[Andrew Haley <aph at redhat dot com>]

Craig A. Vanderborgh writes:
 > Andrew Haley wrote:
 > 
 > >Andrew Haley writes:
 > > > 
 > > >  > Who would've thought?  Our VXML browser application, and our port
 > > >  > of Jetty make strategic use of static linking to limit the immense
 > > >  > libgcj library to only what's actually used by each application,
 > > >  > resulting in a rather large reduction in the size of the
 > > >  > executables.  It's an unexpectedly useful and practical approach.
 > > >  > Too bad static linking doesn't work w/gcj 4.x.
 > > > 
 > > > It works for me.  As far as I can see your current problem is to do
 > > > with NPTL, not gcj.  Did you read the mails you were sent?
 > >
 > >Sorry, I mean linuxthreads.  I really did try to duplicate your
 > >problem as soon as you mentioned it.
 > 
 > I just ran another test to try to track this problem down a little 
 > better.  The test platform was RHEL 4, which has NPTL threads, I 
 > believe.  I built gcc-3.3.6 for RHEL 4, installed it and used it to 
 > rerun the testcase.  But maybe glibc still uses NPTL??

Sorry, I'm getting you confused with someone else.

I'm talking about the "static linking doesn't work" bug, not the
leaking memory bug.  Static linking works for me with 4.0. 

 > ANYWAY, the problem is reduced, but is still present.  To get my test 
 > program to run with stable memory usage, all you have to do is replace 
 > the allocation of Exception/Throwable with something not derived from 
 > Throwable, say Object.  When you do this, the leaking problem completely 
 > goes away.

Ok, so the problem is probably to do with the array that contains the
stack trace.  If you look at gnu.gcj.runtime.StackTrace, you'll see
that it allocates some memory with _Jv_Malloc and then puts a pointer
to this memory in gnu.gcj.runtime.StackTrace.addrs.

I suspect addrs isn't being freed.

Andrew.

 > So what is the domain of this problem, and why do you think it has 
 > something to do with NPTL?  And does GC treat Throwable-derived classes 
 > differently?  Is "_Jv_MarkObj" (boehm.cc) called for ALL objects, 
 > Throwable included?  Or is Throwable handled differently in some 
 > way(s)?  And do expect that I am seeing a C leak from some native code, 
 > or do you think that it's some GC related issue?
 > 
 > We're a little needy right now, but we really are going down in flames 
 > over this.  Please toss me a line if you possibly can.  Just answering 
 > these questions so I can begin to understand the problem would be a 
 > really big help.
 > 
 > Regards,
 > craig