logSelection.cpp : too high tag values show up in some jtreg tests

[Johan Sjolen]

Hi Matthias,

Please see this PR: https://github.com/openjdk/jdk/pull/21185

For some surrounding context: Unified Logging uses a statically defined array size (LogTag::MaxTag) but uses the LogTag::__NO_TAG to signify the end of the array. Think "NULL-terminated string but log tags".

I'll be leaving the PR open to run GHA (I haven't tested it yet).

All the best,
Johan Sjölén

________________________________________
From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.org> on behalf of Baesken, Matthias <matthias.baesken at sap.com>
Sent: Wednesday, September 25, 2024 15:38
To: Stefan Karlsson; hotspot-runtime-dev at openjdk.java.net
Subject: RE: logSelection.cpp : too high tag values show up in some jtreg tests

Hi Stefan, not sure if this is the cause of the issue. If I add a check with a guarantee and build/run without ubsan


@@ -46,6 +46,9 @@ bool LogSelectionList::verify_selections(outputStream* out) const {
       _selections[i].describe_tags_on(out);
       out->print(". ");

+ // added - check that the array entries are okay
+ _selections[i].check_for_bad_tag_array(i, out);
+
       _selections[i].suggest_similar_matching(out);


I see the large  tag  entry values too.

But initializing the whole  _tags  array seems to make sense.
What value should we write  to the entries  ?
And any idea why the initialization was not done for some  ?

Best regards, Matthias


>
>Isn't the problem that the LogSelection constructor doesn't initialize all elements (Only elements that are __NO_TAG gets initialized):
>```
>LogSelection::LogSelection(const LogTagType tags[LogTag::MaxTags], bool wildcard, LogLevelType level)
>    : _ntags(0), _wildcard(wildcard), _level(level), _tag_sets_selected(0) {
>  while (_ntags < LogTag::MaxTags && tags[_ntags] != LogTag::__NO_TAG) {
>    _tags[_ntags] = tags[_ntags];
>    _ntags++;
>  }
>```
>
>And then later when the code copies LogTagType arrays, it hits this ubsan warning when it reads the uninitialized value.. It looks like this could be fixed by always fully initializing _tags memory.