Fatal error while running TSP solver in Java

[Cemal]

Hi, 

I'm running the sample code of TSP solver given in  https://code.google.com/p/or-tools/source/browse/trunk/examples/com/google/ortools/samples/Tsp.java without any problem. I've also modified the code to run for bigger random instances and everything is fine. In addition, I can successfully call this solver within a loop implemented in the main method of the same class. 

However, when I convert this TSP solver to an object and call it from another Java application problem arises : 

First, application executes some lines of code -which are independent from the TSP object- before creating the TSP solver object without any problem. Then, TSP solver object is created and run as expected, report a solution. After that, application runs another lines of code which are again not related to the TSP solver object but I'm getting the following error (see the attached log file for more detail)

#

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

#

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fed6d0af94, pid=5348, tid=1540

#

# JRE version: Java(TM) SE Runtime Environment (8.0_45-b15) (build 1.8.0_45-b15)

# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode windows-amd64 compressed oops)

# Problematic frame:

# C  [jniortools.dll+0xaaf94]

#

# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

#

As far as I understand,  "jniortools.dll" does not free the memory in which JVM want to access. I checked the following most related topics to solve the issue : 

http://stackoverflow.com/questions/17193337/failed-to-write-core-dump-minidumps-are-not-enabled-by-default-on-client-versio

https://community.oracle.com/thread/3590260

Based on those discussions, I tried the following suggestions:

1. changing both or-tools library and JVM from 64 bit to 32 bit, 
   
2. updating JVM, 
   
3. changing workspace directory and changing scope of objects, 
   
4. changing eclipse  config.ini 
   
5. creating the object in a different thread
6. Calling garbage collector after TSP solver object

but none of them solved the problem. 

The only suggestion that I didn't try is downgrading JDK to 1.5 or older because I need to use recent language components (like streams API)  that require the latest JDK.

Another interesting behavior of the application is that some runs are completed successfully without getting the error above. In addition, error message occurs it appears in different steps of the application. For example, if TSP solver object call is at line N, error occurs after executing line N+X where X changes everytime the application is executed  

Thanks in advance for advices. 

---------------  S Y S T E M  ---------------

OS: Windows 7 , 64 bit Build 7601 (6.1.7601.18869)

CPU:total 4 (2 cores per cpu, 2 threads per core) 

Memory: 4k

vm_info: Java HotSpot(TM) 64-Bit Server VM (25.45-b02) for windows-amd64 JRE (1.8.0_45-b15), built on Apr 30 2015 12:40:44 by "java_re" with MS VC++ 10.0 (VS2010)

[Miguel Lara]

Hi 

I have the same problem and I've tried everything.

The program starts running crasch when the collector garbege

Thanks in advance for advices. 

[smile-on]

The crash log clearly points on memory allocation conflict between C++ library and Windows. Java garbage collector (GC) starts cleaning model object that causes operation system (windows) memory access error EXCEPTION_ACCESS_VIOLATION. 

Stack: [0x0000000018980000,0x0000000018a80000],  sp=0x0000000018a7edd0,  free space=1019k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  [jniortools.dll+0xaaf94]

C  [jniortools.dll+0x71d25]

C  0x0000000002925e34

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
..
=>0x00000000176d8000 JavaThread "Finalizer" daemon [_thread_in_native, id=1540, stack(0x0000000018980000,0x0000000018a80000)]
..

  0x0000000001def800 JavaThread "main" [_thread_in_native, id=4196, stack(0x0000000002540000,0x0000000002640000)]

The main method of Java program is waiting on ortools to complete some calculations (which one?) and at same time GC wants free unused RoutingModel that ortools has memory binded to and wants to deallocate it. Two possible scenarios for that:

1) developer memory managment mistake like calling ortools model after model.end() or some similar ortools API that do memory managment,

2) implicist assumption on memory deallocation bihind Java calls in ortools that not obvios to the user. In simple terms Windows deallocated (or disabled access to) that memory already and second call to jniortools.dll library (C++ code) tries to free it. The Java role here is meraly a "second" call of solverJNI.delete_RoutingModel(). It is C++ code that actualy triggers memory error.

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j  com.google.ortools.constraintsolver.operations_research_constraint_solverJNI.delete_RoutingModel(J)V+0 - JVM makes call to C++ library and waits ... for error.

j  com.google.ortools.constraintsolver.RoutingModel.delete()V+25

j  com.google.ortools.constraintsolver.RoutingModel.finalize()V+1

j  java.lang.System$2.invokeFinalize(Ljava/lang/Object;)V+1 - Java GC thinks Model object is not used and has no exteranl references to it.

j  java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V+46

j  java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V+2

j  java.lang.ref.Finalizer$FinalizerThread.run()V+45 - Java GC kicks in

v  ~StubRoutines::call_stub

My understandingit is ether something is wrong in Java code or it is Java wrapper (com.google.ortools.jar) implisitly relies on Java GC cycle "destructor" finalize() to do memory deallocation. This practice is generaly found as not reliable for memory housekeeping and seasonal Java developer knows about it, but may come as complete surprize to C++ guru that used to manage memory by hands and count on its execution at specific time. The best practice in case JNI lib needs to free memory is NEVER implisitly use finalize() but make Java developer awere of requirement to call model.end() and give control over to him.

[Ken Alton]

I've been trying to reproduce the memory access error EXCEPTION_ACCESS_VIOLATION on my ubuntu machine and didn't have any success.  I did however have another problem where if I created enough RoutingModel objects the system would run out of memory and freeze.  It seems that Java GC was not cleaning up these RoutingModel objects at all in my case.  I was able to resolve that issue by calling routingModel.delete() when done with a RoutingModel object and solution.delete() when done with a solution Assignment object.  When I explicitly called System.gc() after doing this the GC didn't try to free the memory again, although I understand that calling System.gc() doesn't guarantee GC is actually run.

Perhaps calling RoutingModel.delete() and then setting it to null to ensure it isn't used again (as suggested in solution #3 http://www.swig.org/Doc1.3/Java.html#proxy_classes_gc, even though this is is a solution to another problem) would also solve the problem you are describing.  Maybe this would ensure that GC doesn't try to free the memory a second time, thus preventing the memory access error.

Ken

--
You received this message because you are subscribed to the Google Groups "or-tools-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to or-tools-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[smile-on]

Ken, thank you for follow up. I did not have problem with TSP myself as well but have different case of EXCEPTION_ACCESS_VIOLATION  and was curios to see what was a rootcase in this TSP thread, simply analyzed crash log.

You are welcome to look at addDimensionWithVehicleCapacity hits Java memory access error EXCEPTION_ACCESS_VIOLATION topic. I put a simple test case to reproduce the problem and would appresiate your feedback.

Slav.

To unsubscribe from this group and stop receiving emails from it, send an email to or-tools-discu...@googlegroups.com.