RFR(S): 8155105: Enhance guardedMemory to detect accessing released memory
David Simms
david.simms at oracle.com
Fri May 6 08:01:44 UTC 2016
Hi,
The change itself looks good, I assume you have made a quick check for
regressions when using "Checked JNI" ("java -version -Xcheck:jni" at
least) ?
A few minor comments:
guardedMemory.hpp:56 needs comment modified to describe the "release
call stack" + freeBlockPad
guardedMemory.hpp:363 "alway" -> "always"
guardedMemory.hpp: In general there's a border-line amount of
implementation code in the header file which could be moved to
guardedMemory.cpp, but that's subjective comment (feel free to ignore).
Some malloc/free implementations are obviously better at debugging this
for you, looks like you are filling a gap for some :-)
Thanks for doing this !
/Mr. Simms
On 29/04/2016 3:22 p.m., Zhengyu Gu wrote:
> This is a debug-only change that is intended to detect accessing
> released memory, ex. double-release a malloc'd memory.
>
> The approach is to rewrite the memory guards with "released" pattern
> and write the calling stack into user data area during os::free() call.
> As the result, verify_memory() check will result a failure if it sees
> "released" guards.
>
> Double-free is not obvious usually, as the memory can be reallocated
> before the second free(). Most of time, it appears to be a
> wild-pointer, -XX:TraceMemoryDoubleFree flag is intended to help to
> identify such scenario, by only building released guards, but not
> actually free the memory, so it can only help when double-free is
> caught before runs out of memory.
>
> When double-free is caught, the two free() call stacks are provided:
>
> ## nof_mallocs = 56722, nof_frees = 9099
> ## memory stomp:
> GuardedMemory(0x00007f85a0a06c30) base_addr=0x00007f859af2f630
> tag=0x0000000000000000 user_size=17 user_data=0x00007f859af2f650
> Header guard @0x00007f859af2f630 is RELASED
> Trailer guard @0x00007f859af2f670 is RELASED
> User data appears to be releasing call stack
> From:
> [0x00007f859f150dc2] os::free(void*)+0x52
> [0x00007f859ec79b5b] GuardedMemory::test_guarded_memory()+0x156b
> [0x00007f859ed02e44] InternalVMTests::run()+0x1d4
> [0x00007f859ed58c15] JNI_CreateJavaVM+0x3e5
> Memory has been released from:
> [0x00007f859ec79b53] GuardedMemory::test_guarded_memory()+0x1563
> [0x00007f859ed02e44] InternalVMTests::run()+0x1d4
> [0x00007f859ed58c15] JNI_CreateJavaVM+0x3e5
> [0x00007f85a01ca753] JavaMain+0x83
>
> Also, updated guarded memory tests to test on "base" pointer (returned
> by ::malloc()) vs "user" pointer (os::malloc()) to reflect real
> runtime scenarios.
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8155105
> <https://bugs.openjdk.java.net/browse/JDK-8155105>
> Webrev: http://cr.openjdk.java.net/~zgu/8155105/webrev/index.html
> <http://cr.openjdk.java.net/%7Ezgu/8155105/webrev/index.html>
>
> Thanks,
>
> -Zhengyu
> <http://cr.openjdk.java.net/%7Ezgu/8155105/webrev/index.html>
>
More information about the hotspot-runtime-dev
mailing list