Hi Matthias,

On 9/12/19 4:52 AM, Baesken, Matthias wrote:

Hi Thomas,   thanks for the review .

You are correct about atoi .

New webrev  :

http://cr.openjdk.java.net/~mbaesken/webrevs/8230901.1/ <http://cr.openjdk.java.net/%7Embaesken/webrevs/8230901.1/>

I had 2 additional  observations  :

 1. With  OJDK on solaris 32bit gone for quite some time, we might be
    able  to kick out the whole  non _LP64  code  because we are
    always 64 bit

(maybe  someone could comment if this is a safe assumption,  there might be old 32bit solaris core files flying around for some reason even these days … )

http://cr.openjdk.java.net/~mbaesken/webrevs/8230901.1/src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp.frames.html <http://cr.openjdk.java.net/%7Embaesken/webrevs/8230901.1/src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp.frames.html>

696   // some older versions of libproc.so crash when trying to attach 32 bit

697   // debugger to 64 bit core file. check and throw error.

698 #ifndef _LP64

…..

 2. The usage of atoi is commented  here :

https://docs.oracle.com/cd/E86824_01/html/E54766/atoi-3c.html

„However, applications should not use the atoi(), atol(), or atoll() functions unless they know the value represented by the argument will be in range for the corresponding result type”

      ……And here :

https://pubs.opengroup.org/onlinepubs/009695399/functions/atoi.html

“If the number is not known to be in range, /strtol/() <https://pubs.opengroup.org/onlinepubs/009695399/functions/strtol.html> should be used because /atoi/() is not required to perform any error checking”

However  we  have  a number of  usages in the coding   where  atoi is called without knowing that  the argument is in the allowed range .

some examples :

src/hotspot/share/runtime/arguments.cpp-382- if (match_option(option, "-Dsun.java.launcher.pid=", &tail)) {

src/hotspot/share/runtime/arguments.cpp:383: _sun_java_launcher_pid = atoi(tail);

src/hotspot/share/runtime/arguments.cpp-384- continue;

src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c

455    value = getenv("_AWT_MAX_POLL_TIMEOUT");

456    if (value != NULL) {

457        AWT_MAX_POLL_TIMEOUT = atoi(value);

src/java.desktop/unix/native/common/awt/X11Color.c-781- if (getenv("CMAPSIZE") != 0) {

src/java.desktop/unix/native/common/awt/X11Color.c:782: cmapsize = atoi(getenv("CMAPSIZE"));

Should I open a bug for these ?


Probably, two different bug are needed: hotspot/runtime and AWT.

Thanks,
Serguei

Best regards, Matthias

*From:*Thomas Stüfe <thomas.stu...@gmail.com>
*Sent:* Donnerstag, 12. September 2019 12:22
*To:* Baesken, Matthias <matthias.baes...@sap.com>
*Cc:* serviceability-dev@openjdk.java.net
*Subject:* Re: RFR [XS]: 8230901: missing ReleaseStringUTFChars in servicability native code

Hi Matthias,

your changes look good.


an additional bug:

http://cr.openjdk.java.net/~mbaesken/webrevs/8230901.0/src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp.frames.html <http://cr.openjdk.java.net/%7Embaesken/webrevs/8230901.0/src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp.frames.html>

 698 #ifndef _LP64
 699   atoi(cmdLine_cstr);
 700   if (errno) {

Behaviour of atoi() in error case is undefined. errno values are not defined.

See: https://pubs.opengroup.org/onlinepubs/009695399/functions/atoi.html

And even if atoi would set errno, this is still not enough since errno may contain a stale value. One would have to set errno=0 before the function call.


If you want to fix this too 'd suggest replacing this call with strtol().

Cheers, Thomas

On Thu, Sep 12, 2019 at 12:11 PM Baesken, Matthias <matthias.baes...@sap.com <mailto:matthias.baes...@sap.com>> wrote:

    Hello, please reviews this small change .

    It adds  ReleaseStringUTFChars calls  at some places in early
    return cases .

    ( in src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp

    THROW_NEW_DEBUGGER_EXCEPTION contains a return , see the macro
    declaration

    39 #define THROW_NEW_DEBUGGER_EXCEPTION(str) {
    throwNewDebuggerException(env, str); return;}

    )

    Bug/webrev :

    https://bugs.openjdk.java.net/browse/JDK-8230901

    http://cr.openjdk.java.net/~mbaesken/webrevs/8230901.0/
    <http://cr.openjdk.java.net/%7Embaesken/webrevs/8230901.0/>

    Thanks, Matthias


Reply via email to