RFR: 8293201: Library detection in runtime/ErrorHandling/TestDwarf.java fails on some systems

[Christian Hagedorn]

On Thu, 1 Sep 2022 08:32:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When building x86_32 on Ubuntu 22.04, the test fails to find the library name in `"C  [libc.so.6+0x85ff1]"`, because the regexp seems too broad. Since we are matching with the unanchored regexp, we can just try and find the smaller prefix, which still matches the library name.
> 
> But the original regexp seems odd to begin with. Why do we match `0x` twice? Why do we have the escaped `\[`, followed by trailing `]` (the last one in the patch now), which is not escaped? This is a question for you, @chhagedorn :)
> 
> Additional testing:
>  - [x] Ubuntu 22.04 x86_32 build

Looks good and trivial! Thanks for fixing that.

> But the original regexp seems odd to begin with. Why do we match 0x twice? 

I've tried to match as much as possible of the output that seemed to be always there to be sure not to match any other lines. But looking at that regex again, it seems I went a little bit over the top. Anyhow, I've (wrongly) assumed that we will always find the offset (second `0x`) of a method in a line:

```V  [libjvm.so+0x6ab1d0]  Compilation::~Compilation()+0x56  (c1_Compilation.cpp:616)```

But it looks like that's wrong and we could only have `"C [libc.so.6+0x85ff1]"`. Matching only on that is indeed enough for that check.

> Why do we have the escaped \[, followed by trailing ] (the last one in the patch now), which is not escaped?

My IDE suggested that I can get rid of the second escape of the closing `]` at the end of the regex (I did not know that I can do that before). It seems to treat it as normal character when there is no (non-escaping) opening `[` before that.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10113