Random java.util.NoSuchElementException exceptions when using perfasm

[Mamontov Ivan]

I had the same issue with JMH. In my case this issue was caused by
environment misconfiguration. By default perf does not record kernel
events, so as a result with the following command:

> perf record --freq 99 --event cycles,instructions --output /tmp/testbin1
> sleep 1

perf script --fields time,event,ip,sym,dso --input /tmp/testbin1


perf reports the following events:

>  4805.282237:       cycles:u:      7fa61e26ccd0 _start+0x0 (/usr/lib64/
> ld-2.24.so)
>  4805.282243: instructions:u:      7fa61e26ccd0 _start+0x0 (/usr/lib64/
> ld-2.24.so)
>  4805.282244:       cycles:u:      7fa61e26ccd0 _start+0x0 (/usr/lib64/
> ld-2.24.so)
>

where u means user space events. Unfortunately jmh expects output like

>  4805.282237:       cycles:      7fa61e26ccd0 _start+0x0 (/usr/lib64/
> ld-2.24.so)
>  4805.282243: instructions:      7fa61e26ccd0 _start+0x0 (/usr/lib64/
> ld-2.24.so)
>  4805.282244:       cycles:      7fa61e26ccd0 _start+0x0 (/usr/lib64/
> ld-2.24.so)


It just replaces each ':' by empty
symbol(org/openjdk/jmh/profile/LinuxPerfAsmProfiler.java:134), i.e.
cycles:u: -> cyclesu. And skips
processing(org/openjdk/jmh/profile/LinuxPerfAsmProfiler.java:160) with
comment "we are not prepared to handle this event, skip"
So in my case all events were skipped without any notification. I think jmh
should take into account such things and report to users in order to not
confuse less experienced users by wrong or empty profiles.



2017-01-18 22:34 GMT+03:00 Bartosz Skrzypczak <barteks2x at gmail.com>:

> While trying to find some way to reproduce a JVM crash with
> JMH+perfasm+gc profiler I got the following exception several times:
>
> # Processing profiler results: LinuxPerfAsmProfiler Exception in
> thread "main" java.util.NoSuchElementException
>     at java.util.TreeMap.key(TreeMap.java:1327)
>     at java.util.TreeMap$NavigableSubMap.firstKey(TreeMap.java:1561)
>     at java.util.TreeSet.first(TreeSet.java:394)
>     at org.openjdk.jmh.profile.AbstractPerfAsmProfiler.figureHotIntervals(
> AbstractPerfAsmProfiler.java:707)
>     at org.openjdk.jmh.profile.AbstractPerfAsmProfiler.makeRegions(
> AbstractPerfAsmProfiler.java:670)
>     at org.openjdk.jmh.profile.AbstractPerfAsmProfiler.processAssembly(
> AbstractPerfAsmProfiler.java:375)
>     at org.openjdk.jmh.profile.AbstractPerfAsmProfiler.afterTrial(
> AbstractPerfAsmProfiler.java:273)
>     at org.openjdk.jmh.runner.Runner.runSeparate(Runner.java:673)
>     at org.openjdk.jmh.runner.Runner.runBenchmarks(Runner.java:542)
>     at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:313)
>     at org.openjdk.jmh.runner.Runner.run(Runner.java:206)
>     at benchmark.TestBenchmark.main(TestBenchmark.java:80)
>
> It's even more rare than the JVM crash I was getting, but unlike the
> JVM crash this is likely to be an issue with JMH. Unfortunately the
> only way I found to maybe get this exception was to run many forks
> (>100) with perfasm and gc profilers. I'm also not sure if the
> benchmark itself also affects it.
>
> Could I also get some information at least where should I report the
> JVM crash and how to get some crash log? It doesn't generage hs_err
> and running with -v EXTRA seems to make the JVM crash go away and
> produces huge logs.
>



-- 
Thanks,
Ivan