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

[Ron Durbin]

From: Coleen Phillimore 
Sent: Monday, February 04, 2013 10:07 AM
To: hotspot-runtime-dev at openjdk.java.net
Subject: Re: Off-by-one error in StackMapFrame::set_mark() breaks -XX:+UseMallocOnly

 


Volker, 

I am assuming this stack is consuming from top to bottom, or another was to say it is” from highest address towards zero.

If so this is the correct fix.

 

Ron

 

 

This looks good.  I'll check this in for you, pending more reviews.  I also added the test because even though it's a nothing-test, it'll test UseMallocOnly and exposes this bug.

open webrev at http://cr.openjdk.java.net/~coleenp/8007475/
bug link at http://bugs.sun.com/view_bug.do?bug_id=8007475

Thanks for sending in the patch.
Coleen

On 1/21/2013 10:35 AM, Volker Simonis wrote:

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/20130204/5e0d019a/attachment.html