RFR: JDK-8151815: Could not parse core image with JSnap.

[Claes Redestad]

Hi,

it seems destroy() used nullness of _prologue to determine that
the counter has already been destroyed, should this use _destroyed
now?

  165   if (_prologue == NULL) return;


/Claes

On 2017-09-26 17:01, Yasumasa Suenaga wrote:
> 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
>>>>