Bug 1019411 - i386 jni NewStringUTF call appends extra character to const char* bytes parameter
i386 jni NewStringUTF call appends extra character to const char* bytes param...
Product: Fedora
Classification: Fedora
Component: java-1.7.0-openjdk (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jon VanAlten
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-15 12:31 EDT by Lukas Berk
Modified: 2015-02-17 12:42 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-02-17 12:42:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Suggested patch for BZ1009306 (3.11 KB, patch)
2013-10-15 12:31 EDT, Lukas Berk
no flags Details | Diff

  None (edit)
Description Lukas Berk 2013-10-15 12:31:23 EDT
Created attachment 812625 [details]
Suggested patch for BZ1009306

Description of problem:
When making a (*env)->NewStringUTF jni call on 32 bit, the const char *bytes parameter appends an extra character to the string.  I could not reproduce this issue on 64 bit.  Before applying the attached patch (meant to address issues found BZ1009306) the call seems to append various extra strings, however after the patch it is always reproducible with only one extra character ("\003")

Version-Release number of selected component (if applicable):
I've reproduced this on Fedora 19 with java-1.7.0 and on RHEL6.5 with java-1.6.0 i386 variants 

How reproducible:

Steps to Reproduce:
1. compile the jni tests included in icedtea6/7 (it is advisable to add the -g compile flag on line ~680) 
2. stap -I/usr/lib/jvm/java/tapset/ -e 'probe hotspot.jni.GetStringUTFLength.return { printf("%sret=%d\n",name,ret) }' -c 'export LD_LIBRARY_PATH=.:/usr/lib/jvm/java/jre/lib/i386/server && ./JNIStapTest GetStringUTFLength

Actual results:

Expected results:

Additional info:
by running gdb on JNIStapTest, it is possible to step through to the JNI call and see the extra character being appended.  This is causing the GetSTringUTFLengthret=7 (instead of the expected 6)


[lberk@localhost tapset]$ LD_LIBRARY_PATH=.:/usr/lib/jvm/java/jre/lib/i386/server gdb --args ./JNIStapTest GetStringUTFLength
(gdb) b 646
Breakpoint 1 at 0x804a8d4: file ./JNIStapTest.c, line 646.
(gdb) r
Starting program: /home/lberk/icedtea7/test/tapset/./JNIStapTest GetStringUTFLength
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x8be53b40 (LWP 31352)]
[New Thread 0x8bdd2b40 (LWP 31353)]
[New Thread 0x8bba4b40 (LWP 31354)]
[New Thread 0x8a1d2b40 (LWP 31355)]
[New Thread 0x8a181b40 (LWP 31356)]
[New Thread 0x89dffb40 (LWP 31357)]
[New Thread 0x89daeb40 (LWP 31358)]
[New Thread 0x89d2db40 (LWP 31359)]
[New Thread 0x89cacb40 (LWP 31360)]
[New Thread 0x89c5bb40 (LWP 31361)]

Breakpoint 1, main (argc=2, argv=0xbffff464) at ./JNIStapTest.c:646
646         char string_chars[6] = {0x57,0x4F,0x52,0x44,0xC0,0x80};
(gdb) n
647         jstring aString = (*env)->NewStringUTF(env, string_chars);
(gdb) p string_chars
$1 = "WORD\300\200"
(gdb) s
jni_NewStringUTF (env=0x805ad28, bytes=0xbffff0de "WORD\300\200\003") at /usr/src/debug/java-1.7.0-openjdk-
3317    JNI_ENTRY(jstring, jni_NewStringUTF(JNIEnv *env, const char *bytes))

the equivalent run on an 86_64/amd64 jvm is below (where the extra character isn't added:

[root@hp-dl360egen8-01 tapset]# LD_LIBRARY_PATH=.:/usr/lib/jvm/java/jre/lib/amd64/server gdb --args ./JNIStapTest GetStringUTFLength
(gdb) b 649
Breakpoint 1 at 0x402c03: file ./JNIStapTest.c, line 649.
(gdb) r
Starting program: /root/icedtea6/test/tapset/JNIStapTest GetStringUTFLength
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff2935700 (LWP 28784)]
[New Thread 0x7ffff2834700 (LWP 28785)]
[New Thread 0x7ffff2733700 (LWP 28786)]
[New Thread 0x7ffff2632700 (LWP 28787)]
[New Thread 0x7ffff2531700 (LWP 28788)]
[New Thread 0x7ffff2430700 (LWP 28789)]
[New Thread 0x7ffff232f700 (LWP 28790)]
[New Thread 0x7ffff222e700 (LWP 28791)]
[New Thread 0x7ffff212d700 (LWP 28792)]
[New Thread 0x7ffff202c700 (LWP 28793)]
[New Thread 0x7ffff1f2b700 (LWP 28794)]
[New Thread 0x7ffff1e2a700 (LWP 28795)]
[New Thread 0x7ffff1d29700 (LWP 28796)]
[New Thread 0x7ffff1c28700 (LWP 28797)]
[New Thread 0x7ffff1b27700 (LWP 28798)]
[New Thread 0x7ffff1a26700 (LWP 28799)]
[New Thread 0x7ffff1925700 (LWP 28800)]
[New Thread 0x7ffff1824700 (LWP 28801)]
[New Thread 0x7ffff1723700 (LWP 28802)]
[New Thread 0x7ffff1622700 (LWP 28803)]
[New Thread 0x7ffff1521700 (LWP 28804)]
[New Thread 0x7ffff1420700 (LWP 28805)]
[New Thread 0x7ffff131f700 (LWP 28806)]
[New Thread 0x7fffeb7f7700 (LWP 28807)]
[New Thread 0x7fffeb6f6700 (LWP 28808)]
[New Thread 0x7fffeb5f5700 (LWP 28809)]
[New Thread 0x7fffeb4f4700 (LWP 28810)]
[New Thread 0x7fffeb3f3700 (LWP 28811)]
[New Thread 0x7fffeb2f2700 (LWP 28812)]
[New Thread 0x7fffeb1f1700 (LWP 28813)]
[New Thread 0x7fffeb0f0700 (LWP 28814)]

Breakpoint 1, main (argc=2, argv=0x7fffffffe188) at ./JNIStapTest.c:649
649         char string_chars[6] = {0x57,0x4F,0x52,0x44,0xC0,0x80};
(gdb) n
650         jstring aString = (*env)->NewStringUTF(env, string_chars);
(gdb) p string_chars
$1 = "WORD\300\200"
(gdb) s
jni_NewStringUTF (env=0x6129d0, bytes=0x7fffffffdbb0 "WORD\300\200")
    at /usr/src/debug/icedtea6-
2086    JNI_ENTRY(jstring, jni_NewStringUTF(JNIEnv *env, const char *bytes))
(gdb) p bytes
$2 = 0x7fffffffdbb0 "WORD\300\200"
Comment 1 Fedora End Of Life 2015-01-09 15:16:05 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 2 Fedora End Of Life 2015-02-17 12:42:01 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.