Off-by-one error in StackMapFrame::set_mark() breaks -XX:+UseMallocOnly

[Volker Simonis]

Hi,

the following debug code in StackMapFrame::set_mark() writes beyond the
bounds of an array allocated with NEW_RESOURCE_ARRAY. This immediately
triggers a "memory stomping error" when running with -XX:+UseMallocOnly:

> output_64_dbg/linux_amd64_compiler2/jvmg/hotspot -showversion
-XX:+UseMallocOnly StackMapFrameTest

Using java runtime at: /share/software/Java/jdk1.7.0_b142/jre
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b142)
OpenJDK 64-Bit Server VM (build 25.0-b16-internal-jvmg, mixed mode)

## nof_mallocs = 56604, nof_frees = 43232
## memory stomp: byte at 0x00007f4cc81c5e20 after object 0x00007f4cc81c5e18
### previous object (not sure if correct): 0x00007f4cc81c5620 (1953 bytes)
### next object: 0x00007f4cc81c5e58 (56 bytes)
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:551
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/share/software/Java/OpenJDK/hsx/hotspot-comp/hotspot/src/share/vm/runtime/os.cpp:551),
pid=22702, tid=139967890032384
#  fatal error: memory stomping error
#

The following patch fixes the problem:

diff -r bf623b2d5508 src/share/vm/classfile/stackMapFrame.hpp
--- a/src/share/vm/classfile/stackMapFrame.hpp  Wed Jan 16 14:55:18 2013
-0800
+++ b/src/share/vm/classfile/stackMapFrame.hpp  Mon Jan 21 16:27:46 2013
+0100
@@ -178,7 +178,7 @@
 #ifdef DEBUG
     // Put bogus type to indicate it's no longer valid.
     if (_stack_mark != -1) {
-      for (int i = _stack_mark; i >= _stack_size; --i) {
+      for (int i = _stack_mark - 1; i >= _stack_size; --i) {
         _stack[i] = VerificationType::bogus_type();
       }
     }

For your convenience, please find attached the small test case and the
patch. I haven't done a JTreg test because the problem only occurs in the
debug version of the VM when running with -XX:+UseMallocOnly which isn't a
tested configuration anyway. Nevertheless I think the -XX:+UseMallocOnly
option (which is also only available in the debug version of the VM) is
important enough (i.e. very nice to hunt other memory problems) to fix the
problem.

Could somebody please open a bug report for this issue (because I still
can't and probably won't be able to until the end of times:) and commit the
patch.

Thank you and best regards,
Volker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/7fb723c3/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stackMapFrame.patch
Type: application/octet-stream
Size: 527 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/7fb723c3/stackMapFrame.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StackMapFrameTest.java
Type: application/octet-stream
Size: 208 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/7fb723c3/StackMapFrameTest.java