JVM crashes with EXCEPTION_ACCESS_VIOLATION

[clo-vis]

What version of OR-tools and what language are you using?
Version: or-tools_VisualStudio2019-64bit_v7.6.7691
Language: Java

Which solver are you using
Routing Solver

What operating system and version?
Microsoft Windows [Version 10.0.16299.1932]

What did you do?
I put the method main of the example TspCities.java in an infinite loop; that is, in that example, I changed
public static void main(String[] args) throws Exception { … }
to
public static void _main(String[] args) throws Exception { … }
and added
public static void main(String[] args) throws Exception { while(true) _main(args); }

What did you expect to see
I expected to see no crash in the JVM

What did you see instead?
The JVM crashed after a few seconds with

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa50da9b2a, pid=8984, tid=11524
#
# JRE version: OpenJDK Runtime Environment (14.0.1+7) (build 14.0.1+7)
# Java VM: OpenJDK 64-Bit Server VM (14.0.1+7, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x349b2a]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows

[Mizux]

First we should test using the C++ sample, i'm pretty sure the leak comes from the SWIG wrapper...

[Mizux]

Coud you try to call the garbage collector between each iteration ?
e.g.

or-tools/examples/tests/TestConstraintSolver.java

Line 339 in 45770b8

gc();

note/ AFAIK this test always fails (90%) on windows CI...

[clo-vis]

If the garbage collector is called after each solution is computed, the JVM does not crash (or, at least, it doesn't crash right after a few seconds). That's what I do now as workaround. For the example above:

public static void main(String[] args) throws Exception {
        while (true) {  _main(args); System.gc(); }
}

By invoking the garbage collector after a couple of solutions are computed, the JVM takes longer to crash, but it crashes eventually.

public static void main(String[] args) throws Exception {
        int i = 0;
        while (true) { _main(args); if (++i % 8 == 0) System.gc(); }
}

[clo-vis]

Another workaround, which is faster, reliable, and works as long as you have enough memory, is storing the reference to all RoutingModel instances created in a static (global) variable:

private static final List<RoutingModel> workaround = new ArrayList<>();

public static void _main(String[] args) throws Exception {
…
    RoutingModel routing = new RoutingModel(manager);
    workaround.add(routing);
…
}

That is, preventing RoutingModel from bein garbage collected also prevents the JVM from crashing.

[HugoSart]

I'm having the same issue. Any updates on this?
Unfortunately, I cannot use the workarounds above due to performance issues.

JVM crash log here: https://pastebin.com/1VJCsa1F

EDIT: I also tested on Debian and Alpine and the problem persists.

[clo-vis]

That is, preventing RoutingModel from bein garbage collected also prevents the JVM from crashing.

No, sooner or later the JVM crashes, no matter which workaround is used.

[Mizux]

IIRC java swig wrapper may use globals to store reference to callback, need to check if it can cause a leak or a double free error causing the JVM to crash, I'll try to investigate it...

note: Usually we only instantiate one routing model, solve it, send/display/save result then close the program, i.e. we spawn one program per instance to solve -> need to add some tests and debug how well a server/daemon in Java is stable.

[Mizux]

Should be fixed on master see:

• Java SWIG wrapper for RoutingModel has a race condition during destruction  #2466

[JavierPelegrin]

It still crashes, i try to run the first example of CP_SAT (https://developers.google.com/optimization/cp/cp_example) and it still crashed.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff9a2eb2c10, pid=5812, tid=1700
#
# JRE version: OpenJDK Runtime Environment (18.0.1.1+2) (build 18.0.1.1+2-6)
# Java VM: OpenJDK 64-Bit Server VM (18.0.1.1+2-6, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C  [msvcp140.dll+0x12c10]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\jpelegri\Documents\maps-algo\maps-algo-planning-constraint\hs_err_pid5812.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

[ChrisMLikesMath]

I see a similar error running the same CP_SAT example file. I get as far as

Starting serach at 0.01s with 12 workers
...
3 helper subsolvers...

Then
# A fatal error has been detected by the JRE
# EXEPTION_ACCESSS_VIOLATION...
# Problematic frame:
# C [MSVCP140.dll...
Using openJDK Corettor