Community
Participate
Working Groups
Build Identifier: If a txt file exists in the same directory as the phd file, and the txt file is not a valid javacore, then it will fail with: Error opening heap dump 'bp.phd'. Check the error log for further details. Error opening heap dump 'bp.phd'. Check the error log for further details. Unable to read dump /data/dumps/bp/bp.phd metafile /data/dumps/bp/bp.txt in DTFJ format DTFJ-PHD (java.io.IOException) Unable to read dump /data/dumps/bp/bp.phd metafile /data/dumps/bp/bp.txt in DTFJ format DTFJ-PHD Error parsing Javacore (java.io.IOException) Error parsing Javacore Not a javacore file. First line: this is some stuff (com.ibm.dtfj.javacore.parser.framework.parser.ParserException) Not a javacore file. First line: this is some stuff This is because the txt file is considered to be a javacore even though it isn't, and it will be passed as the metaFile to the DTFJ ImageFactory.getImage(). This will then fail with the exception described above. The fix is to catch any IOException, then retry without the metaFile. This will cure any problem that has occurred with a bad metaFile. If the IOException was actually something to do with the PHD itself, the second invocation of ImageFactory.getImage() will fail with the same Exception which will be caught and handled in the correct way. Reproducible: Always
Created attachment 191521 [details] Here is a patch to do what is described in the bugzilla
I'm not convinced we need this. It doubles the time to report an error if the main dump file is corrupt. I haven't heard of a problem with people creating a text file of the same base name as the dump. The MAT notes view creates a file called dumpname.notes.txt which doesn't cause problems. DTFJ 1.5 won't read 1.4.2 javacore dumps, but that is unlikely to cause a problem as by default the heap dump and java dumps are named heapdump*.phd and javacore*.txt, so MAT will not pass both dumps to DTFJ. The PHD reader silently ignores the associated javacore it cannot read.
I think this is all down to how people work. I have a number of directories that each contain a number of dumps. A single directory will contain everything concerned with a particular issue that I am working on. Let's assume I have 3 heapdumps in the directory. I want to keep a few notes on each dump reminding my what I was doing when each dump was created. The 3 heapdumps are called: heapdump.20110211.135004.3802.0002.phd heapdump.20110218.122113.5445.0002.phd heapdump.20110311.152435.7882.0002.phd Cleverly, MAT names all it's indices so they have the same basic naming convention and so to list all the files associated with the first heapdump once MAT has run I would type: ls heapdump.20110211.135004.3802.0002.* (Yes, I'm using Linux, but just replace ls with dir if you're a Windows person) Thus, if I was writing some information about the first dump I've got in the habit of giving the file an extension of .txt (probably back from the old DOS days, although lots of editors used to default to .txt for text files) and thus to make sure I can get all the information along with this extra information using the same ls command I would create a file called: heapdump.20110211.135004.3802.0002.txt ... and thus the problem occurs. ... and I have had this problem a couple of times already hence I wrote this fix. Personally, I think the extra time required to fail is negligible and thus the downside is very small.
New Gerrit change created: https://git.eclipse.org/r/127949
Gerrit change https://git.eclipse.org/r/127949 was merged to [master]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=f076708dd7720feef10573d570a9e3890f7bb70d
Okay, I'll fix this. For the record, I've not use the supplied patch, but implemented it myself.
