Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Heapdump indexed on pre-1.16 fails to open on 1.16 #89

Closed
jasonk000 opened this issue Jan 2, 2025 · 3 comments
Closed

Heapdump indexed on pre-1.16 fails to open on 1.16 #89

jasonk000 opened this issue Jan 2, 2025 · 3 comments

Comments

@jasonk000
Copy link
Contributor

Specifically -- an index created on 1.16 cannot be opened on pre-1.16 and triggers re-indexing, likely related to #63.

(I am guessing the reverse also applies, where an old index could not be opened on 1.16).

Seems that the parsing stage. uses ObjectInputStream, which uses reflection to set the ClassImpl.subClasses to a List which it previously was in the old serialized form, to a Set (which it is in the updated implementation).

[Begin task] Reopening parsed heap dump file
[WARNING] Reparsing heap dump file due to cannot as#stance of java.util.LinkedHashSet to field org.eclipse.mat.parser.model.ClassImpl.subClasses of type java.util.List in instance of org.eclipse.mat.parser.model.ClassImpl
java.io.IOException: cannot as#stance of java.util.LinkedHashSet to field org.eclipse.mat.parser.model.ClassImpl.subClasses of type java.util.List in instance of org.eclipse.mat.parser.model.ClassImpl
at org.eclipse.mat.parser.internal.SnapshotImpl.readFromFile(SnapshotImpl.java:273)
at org.eclipse.mat.parser.internal.SnapshotFactoryImpl.openSnapshot(SnapshotFactoryImpl.java:178)
at org.eclipse.mat.snapshot.SnapshotFactory.openSnapshot(SnapshotFactory.java:149)
at org.eclipse.jifa.hda.impl.HeapDumpAnalyzerImpl$ProviderImpl.lambda$provide$0(HeapDumpAnalyzerImpl.java:1970)
at org.eclipse.jifa.hda.impl.HeapDumpAnalyzerImpl.$(HeapDumpAnalyzerImpl.java:189)
at org.eclipse.jifa.hda.impl.HeapDumpAnalyzerImpl$ProviderImpl.provide(HeapDumpAnalyzerImpl.java:1966)
at org.eclipse.jifa.hdp.provider.HeapDumpAnalysisApiExecutor.buildAnalyzer(HeapDumpAnalysisApiExecutor.java:190)
at org.eclipse.jifa.hdp.provider.HeapDumpAnalysisApiExecutor.buildAnalyzer(HeapDumpAnalysisApiExecutor.java:43)
at org.eclipse.jifa.analysis.AbstractApiExecutor.lambda$buildAnalyzer$3(AbstractApiExecutor.java:238)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)

Caused by: java.lang.ClassCastException: cannot as#stance of java.util.LinkedHashSet to field org.eclipse.mat.parser.model.ClassImpl.subClasses of type java.util.List in instance of org.eclipse.mat.parser.model.ClassImpl
at java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2096)
at java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2060)
at java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1347)
at java.base/java.io.ObjectInputStream$FieldValues.defaultCheckFieldValues(ObjectInputStream.java:2679)
at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2486)
at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at org.eclipse.mat.collect.HashMapIntObject.readObject(HashMapIntObject.java:481)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1100)
at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2423)
at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2257)
at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1733)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:509)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:467)
at org.eclipse.mat.parser.internal.SnapshotImpl.readFromFile(SnapshotImpl.java:208)
... 11 more
@jasonk000
Copy link
Contributor Author

I am thinking there might be a few approaches here,

  1. Do nothing, and add an errata/note.

  2. The simplest solution to allow 1.16 to continue opening old index files might be to change Set to Collection. This does not solve the issue of pre-1.16 versions opening a 1.16 index.

  3. Revert the change to store the implementation as a List, and introduce a transient field being a Set, which could be used to accumulate values. We must also introduce then a marker/stamp that if the Set is ever changed, the List will need to be regenerated for reading.

@kgibm
Copy link
Member

kgibm commented Jan 7, 2025

I just hit this problem. This could be a significant issue. For example, our support organization often receives customer dumps that are huge and take about a day to parse; then, they're subsequently re-opened multiple times as the dump is sent between various teams or engineers re-open them on a new working day (we use remote systems through Citrix which are sometimes rebooted over night). This will make transitioning to MAT 1.16 pretty painful in a non-trivial amount of instances. If it's not too much effort, it would be nice if you can add backwards compatibility. I think the issue of a pre-1.16 version trying to open a 1.16 index is not a common issue.

jasonk000 added a commit that referenced this issue Jan 7, 2025
…zation

this was a backwards-incompatible change previously introduced
@jasonk000
Copy link
Contributor Author

@kgibm , I wonder if you can take a look at this early draft? #91

I still need to build/test/verify.

jasonk000 added a commit that referenced this issue Jan 7, 2025
…zation

this was a backwards-incompatible change previously introduced
jasonk000 added a commit that referenced this issue Jan 7, 2025
…impl-ser-deser

fix #89 - read and write List instead of Set during ClassImpl serialization
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants