On 01/06/2016 15:45, Rory O'Donnell wrote: > Hi Mark, > > JDK-8158237 <https://bugs.openjdk.java.net/browse/JDK-8158237> : JVMTI > hides critical debug information for memory leak tracing > > Is closed as a duplicate of JDK-8033735 > <https://bugs.openjdk.java.net/browse/JDK-8033735> : make > Throwable.backtrace visible to Class.getDeclaredField again. > > And this bug was fixed in JDK9 build 116. > > Can you confirm ?
Sorry to be the bearer of bad news, but this bug is NOT fixed. I've just tested this with b120 and b121 and in both cases the memory leak is traceable if I use an HPROF format heap dump but not if I use the YourKit format heap dump obtained via JVMTI. Kind regards, Mark > > Rgds,Rory > > > On 20/05/2016 15:17, Rory O'Donnell wrote: >> Thanks Mark! >> >> >>> On 20 May 2016, at 14:51, Mark Thomas <ma...@apache.org> wrote: >>> >>>> On 19/05/2016 11:05, Rory O'Donnell wrote: >>>> Hi Mark, >>>> >>>> I just had some time to review your email in detail, can you log bugs >>>> for items >>>> 3,4 and 5 and send me the JI numbers ? >>> See in-line. >>> >>> Many thanks, >>> >>> Mark >>> >>>>> 3. Memory leak in sun.rmi.transport.GC >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html >>>>> >>> JI-9038057 >>> >>>>> 4. API to trace RMI Target memory leaks without resorting to >>>>> reflection >>>>> (I accept that this is unlikely but If you don't ask...) >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html >>>>> >>> JI-9038059 >>> >>>>> 5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html >>>>> >>> Looks like someone created a bug for this: >>> https://bugs.openjdk.java.net/browse/JDK-8156841 >>> >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
