RFR(S) 8199924: Solaris: Correctly enqueue null arguments of attach operations (original) (raw)

Langer, Christoph christoph.langer at sap.com
Wed Mar 21 14:00:36 UTC 2018

Hi Dan,

that is, you mean the C-code? My original change?

Best regards Christoph

-----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Mittwoch, 21. März 2018 14:59 To: Langer, Christoph <christoph.langer at sap.com>; David Holmes <david.holmes at oracle.com>; serviceability-dev at openjdk.java.net Subject: Re: RFR(S) 8199924: Solaris: Correctly enqueue null arguments of attach operations

Hmmm... shouldn't the inconsistency in the Solaris backend also be addressed? Dan

On 3/21/18 8:45 AM, Langer, Christoph wrote: > Hi David, > > thanks for looking at this. I currently have no emotions whether to fix it in C or in Java - I'll check it out... > > Best regards > Christoph > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 21. März 2018 10:20 >> To: Langer, Christoph <christoph.langer at sap.com>; serviceability- >> dev at openjdk.java.net >> Subject: Re: RFR(S) 8199924: Solaris: Correctly enqueue null arguments of >> attach operations >> >> Hi Christoph, >> >> On 21/03/2018 6:10 PM, Langer, Christoph wrote: >>> Hi, >>> >>> may I please ask for reviews of the following small fix. >>> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8199924.0/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199924 >>> >>> If one passes null arguments to the varargs of attach operations, they >>> get swallowed on Solaris and following arguments will shift to lower >>> positions. >>> >>> Other platform implementations handle this correctly, for instance >>> linux: >>> >> http://hg.openjdk.java.net/jdk/jdk/file/f6ad4d73c834/src/jdk.attach/linux/cl >> asses/sun/tools/attach/VirtualMachineImpl.java#l178 >> >> Wouldn't it be simpler to just handle this at the Java level and >> substitute "" for null in the args array? We're only looking at a >> maximum of three possible entries. >> >> Thanks, >> David >> >>> Thanks >>> >>> Christoph >>>

More information about the serviceability-dev mailing list