RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Dec 15 06:55:06 UTC 2016


Hi, 

I'm sorry for that. Our solaris builds were fine.
I saw the fix. Thanks Erik for fixing!  I thought
windows was the last platform not to support
declarations in the code.
Do you mind sharing what compiler choked on this?
Maybe we can setup our build accordingly.

And, is there a wiki page that describes which 
files are owned by which mailing list, and to which 
repo to push the corresponding changes?  I've no
idea on the jdk side where to post etc. 

Opening up jprt will be a great step forward!

Best regards,
  Goetz.



> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Wednesday, December 14, 2016 9:55 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> daniel.daugherty at oracle.com; 'Dmitry Samersoff'
> <dmitry.samersoff at oracle.com>; Java Core Libs <core-libs-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> Hi Goetz,
> 
> On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote:
> >
> >> object to the change to k_standard.c for the same reason.
> > Ok, I remove that too.
> 
> I had not realized this was to be pushed directly to jdk9/dev. It broke
> builds on Solaris and so was obviously not tested.
> 
> David
> 
> > Best regards,
> >   Goetz.
> >
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Mittwoch, 14. Dezember 2016 12:29
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> >> daniel.daugherty at oracle.com; 'Dmitry Samersoff'
> >> <dmitry.samersoff at oracle.com>; Java Core Libs <core-libs-
> >> dev at openjdk.java.net>; serviceability-dev (serviceability-
> >> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> >> coding.
> >>
> >> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> You're right, I had removed the change to e_asin.c.
> >>
> >> You only pointed Joe to that file AFAICS. I would expect he would also
> >> object to the change to k_standard.c for the same reason.
> >>
> >>> New webrev anyways:
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> corlib_s11y/webrev.05/
> >>>
> >>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing.
> >>
> >> Okay. Thanks.
> >>
> >> David
> >>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>> Sent: Mittwoch, 14. Dezember 2016 11:42
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff'
> >>>> <dmitry.samersoff at oracle.com>; Java Core Libs <core-libs-
> >>>> dev at openjdk.java.net>; serviceability-dev (serviceability-
> >>>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> servicabilty
> >>>> coding.
> >>>>
> >>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> I found "8169317: [s390] Various minor bug fixes and adaptions."
> >>>>> in jdk9/dev this morning, so I thought it has been promoted based
> >>>>> on some older change. I waited for that quite a while because tests
> >>>>> in jdk9/dev kept failing on s390.
> >>>>> How can I get the information when what was promoted? This always
> >>>>> is a wild guess for me ... as well as when what will be promoted :)
> >>>>
> >>>> Yeah there's no notification in the bug report of when hs pushes up to
> >>>> dev. The changeset email is the only record of exactly when it happens.
> >>>>
> >>>>> Do you think the promotion will happen tonight, or will it take
> >>>>> another week?
> >>>>
> >>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to
> >>>> dev. There have been delays in getting that started and so a delay in it
> >>>> finishing and being analyzed. It may still be a couple of days.
> >>>>
> >>>>> I removed
> >>>>> -                    JLI_StrLen(jrepath) + JLI_StrLen(arch) +
> JLI_StrLen("/lib//jli:")
> >> +
> >>>>> +                    JLI_StrLen(jrepath) + JLI_StrLen(arch) +
> JLI_StrLen("/lib/jli:") +
> >>>>> from
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> corlib_s11y/webrev.04/
> >>>>
> >>>> With that gone that file only has the jvmpath rename - which isn't
> >>>> fixing anything.
> >>>>
> >>>> Joe also asked for the fdlibm changes to dropped.
> >>>>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>>> Best regards,
> >>>>>   Goetz.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04
> >>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff'
> >>>>>> <dmitry.samersoff at oracle.com>; Java Core Libs <core-libs-
> >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability-
> >>>>>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> servicabilty
> >>>>>> coding.
> >>>>>>
> >>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> 8066474 has not been promoted.
> >>>>>>
> >>>>>> hs has not been able to push up to dev yet.
> >>>>>>
> >>>>>>> I'll remove the strlen // fix for aix from this change and
> >>>>>>> push it without it. I'd like to get this done.
> >>>>>>
> >>>>>> I've lost track of what is now left in this set of changes ??
> >>>>>>
> >>>>>> David
> >>>>>>
> >>>>>>> Best regards,
> >>>>>>>   Goetz.
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03
> >>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz
> >>>>>>>> <goetz.lindenmaier at sap.com>; 'Dmitry Samersoff'
> >>>>>>>> <dmitry.samersoff at oracle.com>; Java Core Libs <core-libs-
> >>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability-
> >>>>>>>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> >> servicabilty
> >>>>>>>> coding.
> >>>>>>>>
> >>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote:
> >>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote:
> >>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>> Hi David,
> >>>>>>>>>>>
> >>>>>>>>>>> thanks for looking at the change.  New webrev:
> >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> >>>> corlib_s11y/webrev.04/
> >>>>>>>>>>>
> >>>>>>>>>>>> src/java.base/share/native/libjli/java.c
> >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine.
> >>>>>>>>>>> Ah, thanks for the explanation, now I got it!  Removed.
> >>>>>>>>>>>
> >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output
> string is
> >>>>>>>>>>>> expanded with:
> >>>>>>>>>>>> "%s/lib/%s/jli:"
> >>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since
> >>>>>>>>>>> 8066474,
> >>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc
> >>>>>>>>>>> but the // was not adapted. Then I moved the change to
> jdk9/dev
> >>>>>> because
> >>>>>>>>>>> I thought I have to push it there. And yes, in that coding //
> would
> >>>>>>>>>>> be correct.
> >>>>>>>>>>> So I have to wait until hs is promoted ...
> >>>>>>>>>>
> >>>>>>>>>> So just based on the current file, the change proposed - to
> remove
> >> one
> >>>>>>>>>> / - is not correct until the arch directory is removed.
> >>>>>>>>>
> >>>>>>>>> That change is already in JDK9-hs:
> >>>>>>>>>
> >>>>>>>>> Changeset: c14f9a7b4cab
> >>>>>>>>> Author:    erikj
> >>>>>>>>> Date:      2016-12-05 17:55 +0100
> >>>>>>>>> URL:       http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab
> >>>>>>>>>
> >>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris
> images
> >>>>>>>>> Reviewed-by: tbell, ihse
> >>>>>>>>>
> >>>>>>>>> along with changesets in the jdk and hotspot repos along with a
> few
> >>>>>>>>> closed repos.
> >>>>>>>>
> >>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code -
> >> where
> >>>>>>>> removing the extra / would be correct.
> >>>>>>>>
> >>>>>>>> David
> >>>>>>>> -----
> >>>>>>>>
> >>>>>>>>> Dan
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> David
> >>>>>>>>>> -----
> >>>>>>>>>>
> >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary -
> a
> >>>>>>>>>>>> comment on
> >>>>>>>>>>>> the strdup would have sufficed IMO.
> >>>>>>>>>>> Dmitry asked me to add it.  But I think it's ok.
> >>>>>>>>>>>
> >>>>>>>>>>> Can I consider this reviewed now?  I.e. could I push it once
> 8066474
> >> is
> >>>>>>>>>>> promoted and Joe Darcy agreed?
> >>>>>>>>>>>
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>>   Goetz.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14
> >>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> 'Dmitry
> >>>>>>>> Samersoff'
> >>>>>>>>>>>> <dmitry.samersoff at oracle.com>; Java Core Libs <core-libs-
> >>>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability-
> >>>>>>>>>>>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> >>>>>>>>>>>> servicabilty
> >>>>>>>>>>>> coding.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Goetz,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>> Hi Dmitry,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables.
> >>>>>>>>>>>>> I also merged the ifs in SDE.c.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> new webrev:
> >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> >>>>>> corlib_s11y/webrev.03/
> >>>>>>>>>>>>
> >>>>>>>>>>>> src/java.base/share/native/libjli/java.c
> >>>>>>>>>>>>
> >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine.
> >>>>>>>>>>>> Given a
> >>>>>>>>>>>> jvm.cfg with:
> >>>>>>>>>>>>
> >>>>>>>>>>>> -server KNOWN
> >>>>>>>>>>>> -client IGNORE
> >>>>>>>>>>>> -myvm KNOWN
> >>>>>>>>>>>> -oldvm ALIASED_TO -server
> >>>>>>>>>>>>
> >>>>>>>>>>>> The usage text is:
> >>>>>>>>>>>>
> >>>>>>>>>>>>      -server       to select the "server" VM
> >>>>>>>>>>>>      -myvm         to select the "myvm" VM
> >>>>>>>>>>>>      -oldvm        is a synonym for the "server" VM [deprecated]
> >>>>>>>>>>>>                    The default VM is server,
> >>>>>>>>>>>>                    because you are running on a server-class machine.
> >>>>>>>>>>>>
> >>>>>>>>>>>> which is exactly what I would expect. Why do you think there
> is a
> >>>> bug?
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c
> >>>>>>>>>>>>
> >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output
> string is
> >>>>>>>>>>>> expanded with:
> >>>>>>>>>>>>
> >>>>>>>>>>>> "%s/lib/%s/jli:"
> >>>>>>>>>>>>
> >>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters -
> and that
> >>>>>>>>>>>> is exactly what the existing code does:
> >>>>>>>>>>>>
> >>>>>>>>>>>> + JLI_StrLen("/lib//jli:")
> >>>>>>>>>>>>
> >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary -
> a
> >>>>>>>>>>>> comment on
> >>>>>>>>>>>> the strdup would have sufficed IMO.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> David
> >>>>>>>>>>>> -----
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>   Goetz.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: Dmitry Samersoff
> [mailto:dmitry.samersoff at oracle.com]
> >>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM
> >>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> Java
> >> Core
> >>>>>> Libs
> >>>>>>>>>>>>>> <core-libs-dev at openjdk.java.net>; serviceability-dev
> >>>> (serviceability-
> >>>>>>>>>>>>>> dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib
> and
> >>>>>>>>>>>>>> servicabilty
> >>>>>>>>>>>>>> coding.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Goetz,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> SDE.c:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just
> >>>>>>>>>>>>>> matter of test.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  if (sti == baseStratumIndex || sti < 0) {
> >>>>>>>>>>>>>>         return; /* Java stratum - return unchanged */
> >>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please
> >>>>>>>>>>>>>>> double-check the new webrev.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> if cnt is <= 0 loop at l.267
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) {
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> is never run and we effectively do
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  *entryCountPtr = 0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> at l.283
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0:
> >>>>>>>>>>>>>> (your v.01 changes)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  260         if (sti < 0 && cnt > 0) {
> >>>>>>>>>>>>>>  261             return;
> >>>>>>>>>>>>>>  262         }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> it's better to check it early.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt
> here.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Dmitry
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>>>> Hi Dmitry,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> thanks for looking at my change!
> >>>>>>>>>>>>>>> Updated webrev:
> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> >>>>>>>> corlib_s11y/webrev.02
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c
> >>>>>>>>>>>>>>>> Is this line correct?
> >>>>>>>>>>>>>>>> 519             jvmpath = JLI_StringDup(jvmpath);
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It seems pointless. Should I remove it?  (The whole file is a
> >>>>>>>>>>>>>>> horror.)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c
> >>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0,
> >>>>>>>>>>>>>>>> regardless of value of sti.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please
> >>>>>>>>>>>>>>> double-check the new webrev.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *
> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c
> >>>>>>>>>>>>>>>> It might be better to write
> >>>>>>>>>>>>>>>>   arg.l_linger = (on) ? (unsigned short)value.i : 0;
> >>>>>>>>>>>>>>>> and leave one copy of setsockopt() call
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes, looks better.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>   Goetz
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Dmitry
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code
> >> scans.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability
> >> issues.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Please review:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> >>>>>>>>>>>>>> corlib_s11y/webrev.01/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>   Goetz.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Changes in detail:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> e_asin.c
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Code scan reports missing {}.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the
> inexact
> >>>>>>>>>>>>>>>>> flag of
> >>>>>>>>>>>>>>>>> the processor.
> >>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code
> >> away.
> >>>>>>>>>>>>>>>>> It is
> >>>>>>>>>>>>>>>>> always true,
> >>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to
> submit
> >>>>>>>>>>>>>>>>> this to
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on
> understanding
> >>>>>> these
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> if statements.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> k_standard.c
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be
> >>>>>>>>>>>>>>>>> initialized.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> imageDecompressor.cpp
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Wrong destructor is used.  Reported also by David
> CARLIER
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> java.c
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> java_md_solinux.c
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> SDE.c
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if
> >>>>>>>>>>>>>>>>> defaultStratumId
> >>>>>>>>>>>>>>>>> == null.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> socket_md.c
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use
> is
> >>>>>>>>>>>>>>>>> hidden in
> >>>>>>>>>>>>>>>>> the macros.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> unpack.cpp
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which
> is
> >>>>>>>>>>>>>>>>> passed from
> >>>>>>>>>>>>>>>>> dollar1.
> >>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result
> of
> >>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Dmitry Samersoff
> >>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia
> >>>>>>>>>>>>>>>> * I would love to change the world, but they won't give
> me
> >> the
> >>>>>>>>>>>>>>>> sources.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Dmitry Samersoff
> >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia
> >>>>>>>>>>>>>> * I would love to change the world, but they won't give me
> the
> >>>>>>>>>>>>>> sources.
> >>>>>>>>>


More information about the serviceability-dev mailing list