RFR [XS]: 8235489: handle return values of sscanf calls in hotspot

[Baesken, Matthias]

Hi Kim,  new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8235489.2/


regarding the initialization of "name"  - this is indeed for   lines  without  a name entry -  those lines exist  in /proc/self/maps .
I adjusted the initialization following your recommendation ( handle  matches == 6).

I also changed the unadorned "%s to one with an int-stringsize-parameter .

Best regards, Matthias


> 
> > On Dec 6, 2019, at 10:17 AM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> > Hello,  I noticed there are some remaining sscanf calls  in the hotspot
> codebase missing return value checks.
> > Those should better be checked  .
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8235489
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8235489.0/
> >
> >
> > Thanks, Matthias
> 
> ------------------------------------------------------------------------------
> src/hotspot/os/linux/os_linux.cpp
> 2085       memset(name, 0, sizeof(name));
> 
> What is this line of the change for?  Is this because the pathname
> field in a line can be blank?  That isn't sufficient.  That case needs
> to be handled after the "if (matches < 6) continue;" line, e.g. check
> whether matches == 6 (e.g. a blank name field), forcing "name" to be
> blank if so (e.g. name[0] = '\0').  Otherwise, "name" will contain
> data from the most recent parsed line that contained a match for that
> field.
> 
> ------------------------------------------------------------------------------
> src/hotspot/os/linux/os_linux.cpp
> 2083       char device[6];
> ...
> 2088       int matches = sscanf(line, UINT64_FORMAT_X "-"
> UINT64_FORMAT_X " %4s " UINT64_FORMAT_X " %5s " INT64_FORMAT "
> %s",
> 
> Good eye, spotting the mismatch between the declared size of device
> and the size spec in the format string (e.g. changing "%7s" => "%5s").
> 
> ------------------------------------------------------------------------------
> src/hotspot/os/linux/os_linux.cpp
> 
> In the sscanf format string, there's no length spec for the pathname,
> e.g. it uses an unadorned "%s".  PATH_MAX doesn't deal with long file
> names.
> 
> ------------------------------------------------------------------------------