I'd report it but I'm not sure that there is much that they can do about it. They need to keep references to a lot of this stuff to support debugging operations. The profiling stuff is the same. Very difficult to figure out what is going on without injecting some tooling which starts hanging onto things of interest.
Kirk On May 4, 2011, at 10:04 PM, phil swenson wrote: > I hope you are submitting a bug report to JetBrains :) They are very > responsive.. > > On Wed, May 4, 2011 at 5:21 AM, Jan Goyvaerts <[email protected]> wrote: >> Found the culprit ! >> The memory leak is caused by the debugger of IntelliJ. I'm using break >> points to print a String expression about the progress on the default >> output. Apparently the objects (ie. Foo) used in the expression are not >> released. When disabling the breakpoints no additional Foo's remain in >> memory. So I guess the native code was IntelliJ. >> And moving code to a sub-method seemed to stop the leak because the >> breakpoint was removed. I used a patch to get the windows code to the Linux. >> IntelliJ merged the patch but kept the breakpoints. Hence the Linux was >> leaking while the windows wasn't. :-) >> Now, there's nothing older than two generations. That's a huge relief. >> On Tue, May 3, 2011 at 21:44, Kirk <[email protected]> wrote: >>> >>> On May 3, 2011, at 9:29 PM, Jan Goyvaerts wrote: >>> >>> I was really wondering whether I missed something about garbage >>> collection. Thanks guys ! >>> It's the windows JVM it's working on. It's happily ploughing through all >>> the data and regularly collecting. The Linux version doesn't. :-) >>> Tomorrow I'll double-check the setup to make sure they're as similar as >>> possible. And have a go with Kirk's advice. Didn't though about allocation >>> stack traces indeed... >>> >>> You always want a profiler to provide you with a casual execution path. In >>> this case you want to know how the leaking objects are being created. >>> >>> But I'm positive I had a memory leak on windows with the code in the loop. >>> And no more leak when it was put into a method. So whether it's on Linux or >>> windows - in both cases there's something weird. >>> >>> weird.. my sense is not to trust anything you're saying and perform the >>> memory leak analysis as I've outlined. If the leak is technical, it will >>> show as that. If it's application, it will show up as that. >>> >>> I've been trying on Linux with JDK 1.6 builds 23-25, the latest JDK7 and >>> G1 garbage collection. Same result. >>> >>> I agree the JDBC driver will contain native code - but how on earth can it >>> get a reference to an entity class ? >>> >>> The JDBC driver will use native code but a type IV driver doesn't contain >>> native code. >>> Regards, >>> Kirk >>> >>> >>> >>> 2011/5/3 Cédric Beust ♔ <[email protected]> >>>> >>>> On Tue, May 3, 2011 at 9:44 AM, Kirk <[email protected]> wrote: >>>>> >>>>> On May 3, 2011, at 6:13 PM, Cédric Beust ♔ wrote: >>>>> >>>>>> Hi Jan, >>>>>> >>>>>> Nice job trimming down the list of potential suspects! >>>>>> >>>>>> I think that focusing on locals is a red herring. Locals do get >>>>>> collected and I can't imagine a JVM bug in that area, regardless of the >>>>>> OS, >>>>>> but I have a suspicion your loop is doing some side effects which are >>>>>> causing some other bigger objects to be retained. Sadly, this hypothesis >>>>>> seems to be invalidated by the fact that your code works properly on >>>>>> non-Windows JVM's, but it's not a 100% certainty yet. >>>>>> >>>>> >>>>> Well, having the same code leak in Windows and not in Linux is very much >>>>> smells like a bug. >>>> >>>> Yes, but I was going with Occam's razor here: the bug is more likely to >>>> be in applicative code (e.g. native JDBC drivers, like you suggested) than >>>> in the JVM. >>>> Obviously, you need to keep both in mind until you've ruled one out. >>>> -- >>>> Cédric >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "The Java Posse" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
