0

I have written a short application that converts files from their raw data to XML (ECGs). I have about 350000 files to convert, and the convertion itself is done via a library that I got from the manufacturer of the ECG devices. To make use of multiple processors and cores in the machine I'm using to do the convertion I wrote a "wrapper application" that creates a pool of threads, which is then used to do the convertion in separate threads. It works somewhat ok, but unfortunately I do get random errors causing the whole application to stop (85k files have been converted over the past 3-4 days and I have had four of those errors):

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x71160a6c, pid=1468, tid=1396

JRE version: Java(TM) SE Runtime Environment (8.0_20-b26) (build 1.8.0_20-b26)
Java VM: Java HotSpot(TM) Client VM (25.20-b23 mixed mode windows-x86 )
Problematic frame:
C  [msvcr100.dll+0x10a6c]

I would suspect that it's the library that I'm using that causes these, so I don't think I can do all that much to fix it. If that error happens, I run then program and let it start where it left off before crashing. Right now I have to do that manually but was hoping that there is some way to let Eclipse restart the program (with an argument of the filename where it should start). Does anyone know if there is some way to do that?

Thanks!

Mario Preis
  • 19
  • 4
  • look at http://stackoverflow.com/questions/140030/possible-causes-of-java-vm-exception-access-violation for more details. Possible that this is a duplicate of that question – Fredrik Sep 26 '14 at 06:36
  • Yea, thank you, I should have found that myself... It sounds very similar, and I'm using (or the library is using) native code, DLLs that might play a role. I looked at the hs_err_pid file and don't really understand all too much. Maybe I can upload it somewhere for someone to take a look at. – Mario Preis Sep 26 '14 at 06:42

2 Answers2

1

It is not entirely clear, but I think you are saying that you have a 3rd party Java library (with a native code component) that you are running within one JVM using multiple threads.

If so, I suspect that the problem is that the native part of the 3rd-party application is not properly multi-threaded, and that is the root cause of the crashes. (I don't expect that you want to track down the cause of the problem ...)

Instead of using one JVM with multiple converter threads, use multiple JVMs each with a single converter thread. You can spread the conversions across the JVMs either by partitioning the work statically, or by some form of queueing mechanism.

Or ... you could modify your existing wrapper so that the threads launched the converter in a separate JVMs using ProcessBuilder. If a converter JVM crashes, the wrapper thread that launched it could just launch it again. Alternatively, it could just make a note of the failed conversion and move onto the next one. (You need to be a bit careful with retrying, in case it is something about the file that you are converting that is triggering the JVM crash.)

For the record, I don't know of an existing "off the shelf" solution.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Yea, that sounds about right. :) It does surely look like the 3rd party library/application/native code does not really work with multiple threads (it also looks like that is the case when looking at the console output that my wrapper writes whenever a convertion thread starts; no two or more threads ever start at the same time, there is pretty much always 2 seconds between two of them, and the process of convertion seems to be taking two seconds each. Might not need the threads after all). – Mario Preis Sep 26 '14 at 07:16
  • Ok, so I removed the threading part (didn't do much if anything in this case anyway) and am now using the method you proposed of creating a separate JVM for each conversion using ProcessBuilder. I guess I'll know on monday how well that'll work out, but so far it's looking good :) Thanks again. – Mario Preis Sep 26 '14 at 10:47
  • Wow, I just tried reintroducing multithreading together with using a separate JVM for each conversion, and wow, now it's actually working. Using just one JVM before didn't actually do any threading or at least it looked like it because just one file was converted at a time, but now it's doing 8 at a time. Really awesome. Not sure what the cause was. Maybe that one JVM I used before was only able to access the native DLLs once, and not using 8 threads. But that's just some random guess. – Mario Preis Sep 26 '14 at 11:38
0

It seems that you are using the x86 (32-bit) version of Java. Maybe you could try it with the x64 (64-bit) version. That has sometimes worked for me in the past.

The problem seems to be in the native library, but maybe if you try it with 64-bit Java, it will use a 64-bit version of the native library?

Davio
  • 4,609
  • 2
  • 31
  • 58
  • Unfortunately I don't think I can as the jar library I'm using does not work then. It's not 64 bit compatible. :( – Mario Preis Sep 26 '14 at 06:28
  • Well, threading is treacherous and it could be that you're overloading the native library with too much work. In that case, you might have to go back to one thread. It will take longer, but it won't crash. – Davio Sep 26 '14 at 06:30