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