Troubleshooting

OutOfMemoryError

This kind of issue is often caused when files are parsed by third party libraries with bugs or that were not coded to deal with truncated or corrupted data, commonly recovered by forensic softwares.

To solve it, try to turn on enableExternalParsing option inside profiles/[lang]/conf/AdvancedConfig.txt. This option will do file parsing in external processes, isolating these problems from the main application. So only the external processes will crash, not the main process, and they will be restarted.

Paradoxically this option needs more memory. By default, each processing thread will start one external parsing process with a maximum of 512MB of heap. The maximum heap size and number of external parsing processes can be adjusted with externalParsingMaxMem and numExternalParsers options.

In some very rare cases, it was observed that robustImageReading option, explained below, exhausted the native system memory (OutOfMemoryError: native memory allocation (malloc) failed or OutOfMemoryError: native memory exhausted) because of Sleuthkit memory leaks. Try to disable that option.

If none of the solutions above work, maybe the memory leak was caused by an internal IPED module. Please, check if a *.hprof heap dump file was created in your current directory. If not, run the processing again with -XX:+HeapDumpOnOutOfMemoryError java option. Open an issue, attach the processing log and a link to the compressed heap dump, it will be too large to attach to the issue.

Processing frozen

It rarely occurs, because problematic modules already have timeout control. But, sometimes, new version of libraries have new bugs and very simple tasks, without timeout control, like checking file signatures, could freeze. It will be solved in the future when timeout control is generalized for all modules.

Please report the issue, taking a screenshot of the processing window and a thread dump of iped process, use jvisualvm (comes with oracle jdk8) or jstack (jstack -l ) and attach them to the new issue.

For now, to workaround the problem, take the fullpath of the problematic file from the processing window and create a conf/scripts/IgnoreFile.js script (based on conf/scripts/ExampleScriptTask.js) with a rule like below to ignore the file:

function process(item){
    if(item.getPath().indexOf(path_from_screenshot) != -1){
        item.setToIgnore(true);
    }
}

That script must be installed as the first task in profiles/[lang]/conf/TaskInstaller.xml so other modules will not try to process the file. Starting with version 3.18, you can stop and resume processing from last commit point with --continue option. Older versions do not have resume support and you will need to restart the processing from beginning.

JVM Crashes

Rarely the java virtual machine may crash with a message like this:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f0d05d43315, pid=2219, tid=0x00007f0d0423e700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_131-b31) (build 1.8.0_131-b31)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b31 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x5c5315]  G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*)+0x45
#
# Core dump written. Default location: /aem/author core.2219
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp

When it happens a file named hs_err_pidXXX.log is created with error details in user current directory.

Often this error is caused by bugs in native libraries, sometimes in The Sleuthkit. It can be solved by enabling robustImageReading option in profiles/[lang]/conf/AdvancedConfig.txt. It will open and use external processes to read image (dd/e01) contents. If sleuthkit crashes, only the auxiliary processes will crash, and will be restarted by the main process. You can adjust the number of external processes with numImageReaders option.

Note: A very good side effect of enabling robustImageReading is that processing E01 images will be a lot faster, because file decompression will be done in parallel by all external processes. Without it, sleuthkit must synchronize all reads from E01 images because libewf is not thread safe.

Finally, sometimes this error is caused by bugs in other native libraries used by file parsers (SevenZipParser, EdgeWebCacheParser, SQLiteParser). Turning enableExternalParsing on should solve these cases.