Created pull request with the fix that Ami suggested. https://github.com/google/allocation-instrumenter/pull/16
On Wed, May 4, 2016 at 1:22 PM, Ami Fischman <[email protected]> wrote: > Replied on public issue. > > On Tue, May 3, 2016 at 7:44 PM Remko Popma <[email protected]> wrote: > >> (Added Jeremy Manson and Ami Fischman to recipients) >> >> Guys, we're interested in fixing this concurrency bug in >> AllocationRecorder: >> https://github.com/google/allocation-instrumenter/issues/15 >> >> What would be the best way to accomplish this? >> >> Remko Popma >> >> On Friday, 29 April 2016, Remko Popma <[email protected]> wrote: >> >>> Hi Colin, >>> >>> I'm contacting you because you are listed as one of the contributors to >>> the allocation-instrumenter >>> <https://github.com/google/allocation-instrumenter> project on GitHub. >>> >>> We are working on Log4j 2 <http://logging.apache.org/log4j/2.x/>, and >>> the main theme of the upcoming 2.6 release is making Log4j 2 >>> garbage-free <https://issues.apache.org/jira/browse/LOG4J2-1270> in >>> steady state running. >>> We use the allocation instrumenter in our JUnit tests to verify that >>> things are working as expected. >>> >>> However, on our build server we see our test fail spuriously. >>> I believe this is a bug in AllocationRecorder (to do with accessing a >>> volatile field that has been nulled out by a shutdown hook, details here >>> <https://github.com/google/allocation-instrumenter/issues/15>). >>> >>> Could you please take a look? >>> If you no longer maintain this project, can you point us to the person >>> who does? >>> >>> Many thanks! >>> Remko Popma >>> >>> >>>
