JDK-8213421 : Line number information for execution samples always 0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11,11.0.1,12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-11-06
  • Updated: 2020-04-27
  • Resolved: 2018-12-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 Other
11.0.3-oracleFixed 12 b24Fixed openjdk8u262Fixed
Related Reports
Relates :  
JDK-8239140 - Backport JFR to OpenJDK 8
Description
At Code One 2018, for the Method Profiling part of the HoL, I noticed that the line number information for the method profiling events  (jdk.ExecutionSample event), is always 0.
Comments
Replacing jdk8u-fix-request with link to JDK-8239140
17-02-2020
RFC: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011063.html
30-01-2020
Fix Request This trivial patch is improving JFR reliability. Patch applies cleanly to 11u and passes hotspot tier1 tests.
15-02-2019
I spoke to Erik and Markus to get more info about this bug. To reproduce, you do not need a specific jar or program. Any program will do, as soon as the jdk.ExecutionSample profiling is turned on. Here is what I did: $JAVA_HOME/bin/java -XX:StartFlightRecording:filename=record.jfr,dumponexit=true,settings=profile RunInLoop.java 10 (simple run in loop with sleep, for 10 seconds) $JAVA_HOME/bin/jfr print --events jdk.ExecutionSample record.jfr You can observe line numbers, they are not zero. =========== jdk.ExecutionSample { startTime = 16:00:09.170 sampledThread = "JFR Periodic Tasks" (javaThreadId = 11) state = "STATE_RUNNABLE" stackTrace = [ jdk.jfr.internal.PlatformRecorder.takeNap(long) line: 449 jdk.jfr.internal.PlatformRecorder.periodicTask() line: 441 jdk.jfr.internal.PlatformRecorder.lambda$startDiskMonitor$1() line: 386 jdk.jfr.internal.PlatformRecorder$$Lambda$69.2085002312.run() java.lang.Thread.run() line: 835 ... ] } ========== Verified on: Java(TM) SE Runtime Environment (fastdebug build 12-ea+26) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 12-ea+26, mixed mode, sharing) Mac OSX
09-01-2019
Somehow the following constructor was modified during the move from closed to open: JfrStackFrame(const traceid& id, int bci, int type, int lineno) : _methodid(id), _bci(bci), _type(type), _line(lineno), _meth(NULL) {} to JfrStackFrame(const traceid& id, int bci, int type, int lineno) : _method(NULL), _methodid(id), _line(0), _bci(bci), _type(type) {}
06-11-2018
It can be reproduce with: java -XX:StartFlightRecording:filename=repro.jfr -jar J2Ddemo.jar
06-11-2018