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

[Stefan Karlsson]

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.

StefanK

On 2024-09-25 13:23, Baesken, Matthias wrote:
>
> Hi,  it has been observed (with ubsan,  and also without when adding a 
> little check + guarantee)  that in logSelection.cpp
>
>   we run into very high / messed up  tag values :
>
> [JDK-8333090] ubsan: logSelection.cpp:41:49: runtime error: load of 
> value 32597, which is not a valid value for type 'type' - Java Bug 
> System (openjdk.org) <https://bugs.openjdk.org/browse/JDK-8333090>
>
> When running   jtreg tests cds/appcds/LotsOfClasses  or 
> cds/appcds/cacheObject/ArchivedIntegerCacheTest  we see those high tag 
> values .
>
> Is there someone more familiar with  UL  who has an idea  why the bad 
> tag values occur ?
>
> Or should / can we ignore those  because even bad/uninitialized values 
> work “somehow”  ?
>
> Best regards, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20240925/ef2a63c4/attachment.htm>