RFR (XS) 8148813 - Windows os::check_heap needs more information

Calvin Cheung calvin.cheung at oracle.com
Wed Jun 22 16:50:38 UTC 2016


Hi Ioi,

The fix looks good.

thanks,
Calvin

On 6/21/16, 10:42 PM, Ioi Lam wrote:
>
>
> On 6/21/16 10:38 PM, Ioi Lam wrote:
>>
>>
>> On 6/21/16 10:19 PM, David Holmes wrote:
>>> Hi Ioi,
>>>
>>> On 22/06/2016 2:51 PM, Ioi Lam wrote:
>>>> HI,
>>>>
>>>> Please review a small Windows fix:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8148813
>>>> http://cr.openjdk.java.net/~iklam/jdk9/8148813_windows_check_heap.v01/
>>>>
>>>> We have seen strange heap corruption fatal errors that produced mdmp
>>>> files (windows crash dumps),
>>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8147481
>>>>
>>>> However, when we load these mdmp files in WinDBG, "!heap -triage"
>>>> shows no heap corruption.
>>>>
>>>> These are probably spurious errors reported by HeapWalk. To properly
>>>> diagnose such errors, this patch saves a few of the last seen
>>>> PROCESS_HEAP_ENTRY's into a ring buffer, which can later
>>>> be examined with a debugger.
>>>
>>> I don't understand the use of count or the magic 42. ??
>>>
>> Oops, that was some debug code that shouldn't be there. Here's a 
>> fixed version
>>
>> http://cr.openjdk.java.net/~iklam/jdk9/8148813_windows_check_heap.v02/
>>
>
> BTW, I left the count in the output so we can see how many blocks we 
> have walked before the heap corruption was detected. This info is also 
> useful for diagnosing the spurious errors. The output looks like this:
>
> C heap has been corrupted (time: 1 allocations)
> corrupted block near address 0x356d30, length 32, count 43
>
> Thanks
> - Ioi
>
>


More information about the hotspot-runtime-dev mailing list