RFR: 8293201: Library detection in runtime/ErrorHandling/TestDwarf.java fails on some systems
Christian Hagedorn
chagedorn at openjdk.org
Thu Sep 1 11:54:05 UTC 2022
On Thu, 1 Sep 2022 11:45:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> > 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)`
>
> I see! Yeah, that's unnecessary on the paths that check the missing libraries/symbols.
Indeed!
>
> > > 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.
>
> Oh. My in-brain regex parser threw parse errors at this. Seems like an odd thing to allow, ha!
Right, I also think that's odd :-)
>
> I am sure this fix works in my Ubuntu 22.04 VM, but I am checking that it also fixes GHA: https://github.com/shipilev/jdk/runs/8134142556 -- if so, I'll integrate under trivial rule.
Sounds good.
-------------
PR: https://git.openjdk.org/jdk/pull/10113
More information about the hotspot-runtime-dev
mailing list