Hi all, I added gtest unit test case for this change in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.05/ Could you review it? Thanks, Yasumasa 2017-09-27 0:01 GMT+09:00 Yasumasa Suenaga <yasue...@gmail.com>: > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.04/ > > > Thanks, > > Yasumasa > > > On 2017/09/21 7:45, Yasumasa Suenaga wrote: >> >> PING: >> >> Have you checked this issue? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >> >> >> >> Yasumasa >> >> >> On 2017/07/01 23:43, Yasumasa Suenaga wrote: >>> >>> PING: >>> >>> Have you checked this issue? >>> >>> >>> Yasumasa >>> >>> >>> On 2017/06/13 14:10, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> I want to discuss about JDK-8151815: Could not parse core image with >>>> JSnap. >>>> >>>> >>>> In last year, I found JSnap cannot parse coredump and I've sent review >>>> request for it as JDK-8151815. However it has not been reviewed yet >>>> [1]. >>>> >>>> We've discussed about safety implementation, but we could not get >>>> consensus. >>>> IMHO all SA tools should be handled java processes and core images, >>>> and PerfCounter value is useful. So I fix this issue. >>>> >>>> I uploaded new webrev for this issue. I think this patch is safety >>>> because new flag PerfMemory::_destroyed guards double free, and all >>>> members in PerfMemory is accessible (they are not munmap'ed) >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >>>> >>>> >>>> Can you cooperate? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019480.html >>>> >
