-
Bug
-
Resolution: Fixed
-
P3
-
25
-
b26
(change synopsis as you see fit)
SonarCloud reports a problem sinceJDK-8355003 integration.
Seems to unfold like this:
KlassTrainingData* KlassTrainingData::make(InstanceKlass* holder, bool null_if_not_found) {
...
}
...eventually calls:
static KlassTrainingData* allocate(InstanceKlass* holder) {
return TrainingData::allocate<KlassTrainingData>(holder);
}
...which eventually calls:
KlassTrainingData::KlassTrainingData(InstanceKlass* klass) : TrainingData(klass) {
if (holder() == klass) {
return; // no change to make
}
...which accesses:
InstanceKlass* holder() const { return _holder; }
...but _holder is not yet initialized! So the check in KlassTrainingData::KlassTrainingData accesses garbage data.
SonarCloud reports a problem since
Seems to unfold like this:
KlassTrainingData* KlassTrainingData::make(InstanceKlass* holder, bool null_if_not_found) {
...
}
...eventually calls:
static KlassTrainingData* allocate(InstanceKlass* holder) {
return TrainingData::allocate<KlassTrainingData>(holder);
}
...which eventually calls:
KlassTrainingData::KlassTrainingData(InstanceKlass* klass) : TrainingData(klass) {
if (holder() == klass) {
return; // no change to make
}
...which accesses:
InstanceKlass* holder() const { return _holder; }
...but _holder is not yet initialized! So the check in KlassTrainingData::KlassTrainingData accesses garbage data.
- caused by
-
JDK-8355003 Implement JEP 515: Ahead-of-Time Method Profiling
-
- Resolved
-
- relates to
-
JDK-8358580 Rethink how classes are kept alive in training data
-
- Open
-
- links to
-
Commit(master) openjdk/jdk/ae1892fb
-
Review(master) openjdk/jdk/25623