Examples with InvalidDumpFormatException com.ibm.j9ddr.corereaders.InvalidDumpFormatException used on opensource projects

Example 1 with InvalidDumpFormatException

use of com.ibm.j9ddr.corereaders.InvalidDumpFormatException in project openj9 by eclipse.

the class ELFDumpReader method readThread.

// Reads the prstatus structure.
private IOSThread readThread(DataEntry entry) throws IOException {
    _reader.seek(entry.offset);
    // signalNumber
    _signalNumber = _reader.readInt();
    // Ignore code
    _reader.readInt();
    // Ignore errno
    _reader.readInt();
    // Ignore cursig
    _reader.readShort();
    // Ignore dummy
    _reader.readShort();
    // Ignore pending
    _reader.readElfWord();
    // Ignore blocked
    _reader.readElfWord();
    long pid = _reader.readInt() & 0xffffffffL;
    // Ignore ppid
    _reader.readInt();
    // Ignore pgroup
    _reader.readInt();
    // Ignore session
    _reader.readInt();
    // utime_sec
    long utimeSec = _reader.readElfWord();
    // utime_usec
    long utimeUSec = _reader.readElfWord();
    // stime_sec
    long stimeSec = _reader.readElfWord();
    // stime_usec
    long stimeUSec = _reader.readElfWord();
    // Ignore cutime_sec
    _reader.readElfWord();
    // Ignore cutime_usec
    _reader.readElfWord();
    // Ignore cstime_sec
    _reader.readElfWord();
    // Ignore cstime_usec
    _reader.readElfWord();
    // Registers are in a elf_gregset_t (which is defined per platform).
    SortedMap<String, Number> registers = readRegisters();
    Properties properties = new Properties();
    properties.setProperty("Thread user time secs", Long.toString(utimeSec));
    properties.setProperty("Thread user time usecs", Long.toString(utimeUSec));
    properties.setProperty("Thread sys time secs", Long.toString(stimeSec));
    properties.setProperty("Thread sys time usecs", Long.toString(stimeUSec));
    if (pid == _pid) {
        // main thread (in Linux JVM fork&abort case this is the only thread)
        for (DataEntry registerEntry : _highwordRegisterEntries) {
            try {
                readHighwordRegisters(registerEntry, registers);
            } catch (InvalidDumpFormatException e) {
                logger.warning(e.toString());
            }
        }
    }
    return new LinuxThread(pid, registers, properties);
}

Example 2 with InvalidDumpFormatException

use of com.ibm.j9ddr.corereaders.InvalidDumpFormatException in project openj9 by eclipse.

the class ELFDumpReader method readModules.

/**
 * Read all modules in the core file, where "modules" = the executable and all
 * shared libraries. Put the executable into _executable and the libraries without
 * the executable into _modules.
 * <p>
 * Find libraries by two methods: iterating through all the segments in the core
 * file looking for which are libraries and iterating through the debug information
 * within the executable. We may find the executable either on disk, within the
 * core file as one of the loaded segments, or appended to the core file by
 * library collections. Consolidate the list of libraries that we find from the
 * debug information with the list from the core file to build the best list possible.
 * <p>
 * When constructing the module objects, use the best available data. This means using
 * the section header information from the collected libraries if present since this
 * is always more reliable than that in the core file.
 *
 * @throws IOException
 */
/* In a second comment to avoid it appearing in hovertext
	 * 
	 * This method is called under at least two completely different circumstances:
	 * 
	 * Circumstance 1 - called during library collection when there are not yet any collected libraries
	 * appended to the core file. In this case all that is really wanted is a list of the 
	 * names of the libraries to guide the collection but this method does not discriminate and 
	 * constructs everything possible, reading section header tables and symbol tables and so on. 
	 * In this case the aim is to return the most complete list of modules, examining both the 
	 * modules within the core file and the list that can be found from the debug data in the 
	 * executable. 
	 *  
	 * Circumstance 2 - called when it is important to have the best possible information about
	 * each module - as for example when called from jdmpview. In this case the collected libraries 
	 * may or may not be appended to the core file but if they are then the section header information 
	 * is always better when taken from the collected library so the modules should be constructed 
	 * from the them. 
	 * 
	 * The reason it is important to keep an eye on both circumstances is that they affect one another.
	 * In circumstance 1, some of the constructed modules are of poor quality because the original library is not
	 * available. In circumstance 2, whether or not the library will be found appended to the core file
	 * depends on whether it was found and returned in circumstance 1. 
	 * 
	 * TODO refactor so that the code paths for the two circumstances are not so entwined. Separate out the 
	 * two functions of gathering the list of names of which libraries exist, needed for both circumstances, and constructing
	 * the best possible image of each library, using core and collected library, only needed for the second circumstance. 
	 * 
	 * There are three sorts of module, too. 
	 * 1. Those found only via the program header table of the core file. This includes most of the system
	 * libraries e.g. ld-linux.so.2. These only have the library name, no path, because they are found from 
	 * the SOname within the module.
	 * 2. Those found only via the debug data in the executable. This can include several of the j9 libraries.
	 * They are present within the core file but the route to the SOname is broken somehow
	 * 3. Those found both ways - most of the j9 libraries are in this case. However note that the 
	 * names will be different because the names found via the debug data are full pathnames and the 
	 * names found via the SOname is just the library name. However they can be matched up via the load
	 * address which is available on both routes. 
	 * 
	 * There are a some oddities too:
	 * 1. the executable always appears in the core file with a SOname of "lib.so"
	 * 2. The core file always contains a library called linux-gate.so which does not correspond to 
	 * a file on disk
	 * 3. Sometimes the same file - e.g. libvmi.so, and the executable itself - will be mapped into memory 
	 * twice or more at different addresses so the same name will appear more than once in the 
	 * list from the core file.
	 */
private void readModules() throws IOException {
    if (_executable == null || _executable instanceof MissingFileModule) {
        _modulesException = null;
        _modules = new LinkedList<IModule>();
        readProcessData();
        // Try to find the executable image either on disk or appended to the core file by library collection.
        // If we can we will probably also find the libraries on disk or appended to the core file and will
        // therefore get good section header tables.
        // Otherwise use the copy of the executable within the core file. It may contain some of the library info
        // so it makes a good fallback.
        LibraryDataSource executableFile = findExecutableOnDiskOrAppended();
        ELFFileReader executableELF = null;
        if (executableFile != null && executableFile.getType() != LibraryDataSource.Source.NOT_FOUND && !useLoadedLibraries) {
            try {
                executableELF = getELFReaderFromDataSource(executableFile);
            } catch (InvalidDumpFormatException e) {
            // Not an ELF file.
            }
            if (null != executableELF) {
                createAllModules(executableELF, executableFile.getName());
            }
        } else if (_executable instanceof MissingFileModule) {
            logger.log(Level.FINE, "Libraries unavailable, falling back to loaded modules within the core file.");
            executableELF = getELFReaderForExecutableWithinCoreFile();
            if (null != executableELF) {
                createAllModules(executableELF, _executablePathOverride);
            } else {
                _executable = new MissingFileModule(_process, _executableFileName, Collections.<IMemoryRange>emptyList());
            }
        } else {
            _executable = new MissingFileModule(_process, _executableFileName, Collections.<IMemoryRange>emptyList());
        }
    }
}

Example 3 with InvalidDumpFormatException

use of com.ibm.j9ddr.corereaders.InvalidDumpFormatException in project openj9 by eclipse.

the class AIXDumpReader method getReaderForFile.

public static ICore getReaderForFile(File file) throws IOException, InvalidDumpFormatException {
    ClosingFileReader reader = new ClosingFileReader(file, ByteOrder.BIG_ENDIAN);
    // Read first few bytes to check this is an AIX dump
    byte[] buffer = new byte[128];
    reader.readFully(buffer);
    if (!isAIXDump(buffer, file.length())) {
        reader.close();
        throw new InvalidDumpFormatException("File " + file.getAbsolutePath() + " is not an AIX dump");
    }
    reader.seek(CORE_FILE_VERSION_OFFSET);
    int version = reader.readInt();
    boolean is64Bit = false;
    if (version == CORE_DUMP_X_VERSION) {
        // Could be a 64 bit if generated on a pre-AIX5 machine
        reader.seek(CORE_DUMP_X_PI_FLAGS_2_OFFSET);
        int flags = reader.readInt();
        is64Bit = (S64BIT & flags) != 0;
    } else if (version == CORE_DUMP_XX_VERSION) {
        // All core_dump_xx are 64 bit processes
        is64Bit = true;
    } else {
        throw new InvalidDumpFormatException("Unrecognised core file version: " + Long.toHexString(version));
    }
    if (is64Bit) {
        return new AIX64DumpReader(file, reader);
    } else {
        return new AIX32DumpReader(file, reader);
    }
}

Example 4 with InvalidDumpFormatException

use of com.ibm.j9ddr.corereaders.InvalidDumpFormatException in project openj9 by eclipse.

the class AIXDumpReader method getReaderForFile.

public static ICore getReaderForFile(ImageInputStream in) throws IOException, InvalidDumpFormatException {
    // Read first few bytes to check this is an AIX dump
    byte[] buffer = new byte[128];
    in.seek(0);
    in.read(buffer);
    // because of the stream parameter we can't check the file length, so this weakens an already weak AIX validation
    if (!isAIXDump(buffer, Long.MAX_VALUE)) {
        throw new InvalidDumpFormatException("The supplied input stream is not an AIX dump");
    }
    in.seek(CORE_FILE_VERSION_OFFSET);
    int version = in.readInt();
    boolean is64Bit = false;
    if (version == CORE_DUMP_X_VERSION) {
        // Could be a 64 bit if generated on a pre-AIX5 machine
        in.seek(CORE_DUMP_X_PI_FLAGS_2_OFFSET);
        int flags = in.readInt();
        is64Bit = (S64BIT & flags) != 0;
    } else if (version == CORE_DUMP_XX_VERSION) {
        // All core_dump_xx are 64 bit processes
        is64Bit = true;
    } else {
        throw new InvalidDumpFormatException("Unrecognised core file version: " + Long.toHexString(version));
    }
    if (is64Bit) {
        return new AIX64DumpReader(in);
    } else {
        return new AIX32DumpReader(in);
    }
}

Example 5 with InvalidDumpFormatException

use of com.ibm.j9ddr.corereaders.InvalidDumpFormatException in project openj9 by eclipse.

the class MiniDumpReader method processDump.

public ICore processDump(String path) throws FileNotFoundException, InvalidDumpFormatException, IOException {
    File file = new File(path);
    // MiniDump files can be Little Endian only.
    this.coreFile = file;
    ClosingFileReader fileReader = new ClosingFileReader(file, ByteOrder.LITTLE_ENDIAN);
    if (!isMiniDump(fileReader)) {
        throw new InvalidDumpFormatException("The file " + file.getAbsolutePath() + " is not a valid MiniDump file.");
    }
    setReader(fileReader);
    return this;
}