I think it should return false like is does with verify_tag(). This will
cause the test to fail, which it what we would want in this case
Chris
On 9/13/23 11:20 PM, David Holmes wrote:
Hi Julian,
This is a serviceability issue - cc'd.
On 14/09/2023 12:48 pm, Julian Waters wrote:
Hi all,
In the HotSpot
test /test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp,
the method occurance_expected, which returns a jboolean, returns
JNI_ERR in an error condition. The only place this is used is on line
383, at
https://github.com/openjdk/jdk/blob/11d431b2c436d6b2a0aa7a00d676a93c1b87da0e/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp#L383
<https://github.com/openjdk/jdk/blob/11d431b2c436d6b2a0aa7a00d676a93c1b87da0e/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp#L383>.
There is no special handling for the JNI_ERR condition as far as I
can tell, and since jboolean is unsigned, the JNI_ERR value of -1
will end up becoming 255 when returning from this method, which is
then interpreted as JNI_TRUE on line 385. I caught this after
redefining jboolean to bool, which then caused the microsoft compiler
to warn about truncating the value. This seems like a bug to me,
since I don't think it should return true on an error condition, is
there something I'm missing?
That's a bug. Unclear whether they intended JNI_FALSE like verify_tag,
or whether this was really intended to be an error. If it is an error
then the test should abort somehow.
Cheers,
David
best regards,
Julian
