Sorry, meant to address Christoph, not Thomas.
Chris
On 3/5/18 9:17 AM, Chris Plummer wrote:
Hi Thomas
Asserts imply something that is suppose to never happen, but that you
want to check for in debug builds to help uncover bugs. Given this,
either we have a bug (and someone can pass in a name that is too
long), or coverity is complaining about something that can never
happen, or the assert is invalid. So the potential fixes are:
-Fix the problem up the call chain were the invalid string can be
passed in.
-Tell coverity to clam up because having the string be too long is not
possible.
-Leave in your fix but remove the assert.
thanks,
Chris
On 3/5/18 7:37 AM, Langer, Christoph wrote:
Hi Thomas,
well, I think this discussion is beyond the scope of my contribution.
Probably one doesn’t want the risk of JVM crashes/exits just
because someone shoots in a bad attach operation name which is too long.
So, may I consider it reviewed from your end? I’m trying the
submission repo right now with this change…
Best regards
Christoph
From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
Sent: Montag, 5. März 2018 15:53
To: Langer, Christoph <christoph.lan...@sap.com>
Cc: Hotspot dev runtime <hotspot-runtime-...@openjdk.java.net>;
serviceability-dev@openjdk.java.net
Subject: Re: RFR (XS): 8199010: attachListener.hpp: Fix potential
null termination issue found by coverity scans
Hi Christoph,
Seeing that truncation is considered assertion worthy, should we
really hide it in release?
Gruß Thomas
On Mar 5, 2018 10:03, "Langer, Christoph"
<christoph.lan...@sap.com<mailto:christoph.lan...@sap.com>> wrote:
Hi,
please review a small fix that was identified by a coverity code scan.
In case strlen(name) was the same or larger than name_length_max or
resp. strlen(arg) >= arg_length_max, the _name or _arg fields would
not get null terminated correctly.
Bug: https://bugs.openjdk.java.net/browse/JDK-8199010
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8199010.0/
Thanks
Christoph
