JDK-8248878 : SA: Implement simple workaround for JDK-8248876
- Type: Sub-task
- Component: hotspot
- Sub-Component: svc-agent
- Affected Version: 16
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: linux
- Submitted: 2020-07-06
- Updated: 2020-07-23
- Resolved: 2020-07-15
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.
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 16 |
|---|
16 b07Fixed  |
Related Reports
|
Blocks :
|
Description
I'd like to add the following work around for JDK-8248876 so it no longer causes an NPE every time you try to use "findpc" functionality for the work being done for JDK-8247514. The only user of the LoadObjects that cares about the "base" address is loadObjectContainingPC(). The easy fix is to just add a null check before using "base" to determine if the PC is in the LoadObject:
if (base == null) continue; // Skip. LoadObject was not properly initialized.
if (pc.greaterThanOrEqual(base) && pc.lessThan(base.addOffsetTo(size))) {
return ob;
}
The only short coming of this fix is that address -> symbol lookups for addresses in the exec file (bin/java) will fail. This is not something that an SA user is ever likely to run into. Symbols of interest are typically in libjvm.so.
Comments
|