Menu
▾
▴
1 Attachments
#15 JVM Crash when extracting file
I have a somewhat unique situation where I am trying to extract different files from the same archive in multiple threads. I have isolated the extractions as much as possible using separate RandomAccessFiles, ISevenZipInArchives, etc. This works initially (IE 1.5 files get processed), however randomly the entire JVM will crash in the middle of extracting one of the files. I've attached the basic crash report and can provide additional information if needed
Just in case its relevant the extraction process is essentially this:
1) Open the archive and list the files in the main directory. Create an individual "ArchiveEntry" for each file which will create its own RandomAccessFile and ISevenZipInArchive
2) Sometime later, extract and parse each file in a separate thread. Since I need an InputStream to be consumed by the rest of my application, the actual ISevenZipInArchive.extract() is called in its own thread. The Callback writes to a PipedOutputStream which is put into the PipedInputStream given to my application.
Essentially, a somewhat complex thread model is somehow causing 7zipJBind to crash even though I've isolated each extraction. Any ideas what could possibly cause this? Is this a bug in 7zipJBind? Is there any more information you need to get this resolved?
(Note: I also tried a shared ISevenZipInArchive but that crashed almost immediately)
I have some extra time so I'm going to try to track this down. I managed to compile the latest dev version in the repo in debug mode (set CMAKE_BUILD_TYPE in CmakeLists) on Windows using GCC 4.6.2. The problem I'm having is that I'm a beginner at C++ and know almost nothing about debugging it.
The closest I got to something useful was this error before the crash (I attached the log too):
FATAL ERROR: Out of local resource of out of memory: byteArray == NULL
Crash jvm to get a stack trace
Ok, memory problem is a good guess. Running with -Xmx512m it still crashes but points to this frame
C [lib7-Zip-JBinding.dll+0xcb77] Java_net_sf_sevenzipjbinding_SevenZip_nativeOpenArchive+0x3cb7
Increasing it more with -Xms512m -Xmx1024m seems to reliably print "Execution protection violation" before the crash and always points to 0x00000000 as the problem frame.
I could test higher but I can't figure out how to successfully compile an x64 version of sevenzipjbinding. I also can't use visual studio to just figure out where the problem line is since it doesn't compile with the VS compiler nor with the gcc compiler.
I (now) have the tools on my system to help debug this issue, but I'll need help to get helpful information out of them
Hello Franz,
thank you very much for helping with this problem. 7-Zip-JBinding should compile with CMake + gcc on all platforms. Take a look of "Compile on Windows" section of
https://github.com/borisbrodski/sevenzipjbinding
check also
https://github.com/borisbrodski/sevenzipjbinding/blob/master/scripts/doDebug-Win64.bat
I also attached Windows 64 Debug version of 7-Zip-JBinding v4.65-1.06-rc-extr-only.
Speaking of out of memory, it is possible, that a broken archive file forces 7-Zip to allocate very large amount of memory (this would be a bug of couse). Are you sure all your archives can be extracted by 7-Zip-JBinding in a single thread environment?
Another question: How many threads do you need to make 7-Zip-JBinding crash?
Regards,
Boris
After alot more testing I've isolated things to this error
FATAL ERROR: The referenced object NativeMethodContext (this: 0x0C57EF00) was destructed
Essentially ISevenZipInArchive cannot be closed in a different thread. This is most likely my fault as I have a race between extract() fully completing and close() running. Moving close() to directly after calling extract() fixes the issue. This even works in the latest release.
While this is my fault, the problem I have is the way the error is reported. JVM crashes with C stack traces are extremely hard to debug and lead people to blame the library before they look at their code.
Shouldn't the extraction process fully stop when close() is called? What could be called afterwords that I assume is being GC'd?
Close if you want
Hello Leon,
if the problem still present, could you please test it with the new 7-Zip-JBinding 2.00?
Thank you.
Cheers,
Boris