[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator (Code Analysis Discussion)
From:       Eric Bresie <ebresie () gmail ! com>
Date:       2019-12-21 17:13:07
Message-ID: CAHw6w1Qq+xF=PJvXwN2uDK_FCv3isBSGQC_pdvqAjXTPc4uJeA () mail ! gmail ! com
[Download RAW message or body]

Accepting that static analysis tools are not best at finding memory
leaks...however they can find some easy to find ones.  I was just wondering
if some of these can be run across the code base to find these "easy to
find" ones to help in the process.

Additionally, if there are certain checks that want to be flowed out across
the code base (i.e. checks for initialization, then having the analysis run
as part of a CI build jobs which could be periodically run and reported on
to might help maintain some level of code quality over time.  I know this
can potentially find a lot of false failures but just thought it might be
worth considering at some point.

Eric Bresie
ebresie@gmail.com


On Fri, Dec 20, 2019 at 7:30 AM Kevin Rushforth <kcr@openjdk.java.net>
wrote:

> On Fri, 20 Dec 2019 09:53:56 GMT, Florian Kirmaier <fkirmaier@openjdk.org>
> wrote:
>
> >> @dsgrieve
> >> It's worth mentioning that JavaFX already has many tests based on
> System.gc().
> >> An advantage of having a testsuit as an library (or copyied from an
> library) is, that its stability is regulary verified by the travis builds
> for different JVMs.
> >> The alternative would be to not test for memory-leaks at all which is
> much worse than having slightly unstable tests.
> >> Maybe it can make sense to seperate these tests for leaks in an own
> testgroup.
> >>
> >> I'm introducing this library in more and more projects. I never had
> problems with unstable tests.
> >> I only had this kind of problem when I wrote the
> WeakReference/System.gc/sleep-logic for every single test.
> >
> > I highly doubt that a code analysis tool will find such memoryleaks.
>
> I agree. Static analysis tools are quite limited in this regard, and are
> in now way a substitute for regression testing.
>
> So the question is how best to test fixes for memory leaks at runtime. Our
> current approach can be best characterized as "ad hoc", and is not all that
> robust (although works well enough in most cases and is still much better
> than doing no testing at all). I would welcome discussion of a more robust
> approach for testing, but it should be decoupled from this bug fix, and
> discussed as a separate JBS Enhancement request.
>
> -------------
>
> PR: https://git.openjdk.java.net/jfx/pull/71
>
[prev in list] [next in list] [prev in thread] [next in thread]