CPU load goes much higher when load twice

[CTH-launch]

What language and solver does this apply to?
java

Describe the problem you are trying to solve.
java program,
loaded in one thread, then another thread load while running alg-thing using jdk,
CPU-load goes much higher but CPU-idle is normal, which means some of core over used,
after a while, main process interrupt, and make coredump

but this will not happen, if only load once

someone has same issue?
help!!! may day!!!

[lperron]

I do not understand the issue.
Please indicate which solver you are using too.

[Mizux]

Which solver/component did you use ? CP-SAT, LinearSolver ? HiGHS ?

[CTH-launch]

CP-SAT

[lperron]

are you exhausting all memory ?

[CTH-launch]

no, normal memory usage
but,
high load average(higher than 1), low cpu usage(cpu idle keep aroud 80%), high disk io(may appear, but not every time)

[CTH-launch]

@Mizux @lperron Any ideas for troubleshooting? thx.

[lperron]

I do not understand what is happening. I have no logs. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le mer. 25 juin 2025 à 11:49, CTH-launch ***@***.***> a écrit :

…

@Mizux <https://github.com/Mizux> @lperron <https://github.com/lperron> Any ideas for troubleshooting? thx. — Reply to this email directly, view it on GitHub <#4695 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3NDAYE72AN6ODVIUFD3FJWENAVCNFSM6AAAAAB7UY6UGSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJXGE4DKNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[CTH-launch]

'''
thead-1 execute:
class A:
system.load(solver)

thead-2 execute:
class B:
run service from JAR

service in JAR:
system.load(solver)
'''

same solver path, same solver version, same solver package

when executing thead-2, CPU-load average goes higher than 1, CPU-idle is ok, memory use is ok

maybe you can try this to recur

I've tried to use jstack to see what happend, but coredump came so fast.

[lperron]

Does not help. Can you send the solver log of the 2 threads ? Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le jeu. 26 juin 2025, 09:26, CTH-launch ***@***.***> a écrit :

…

''' thead-1 execute: class A: system.load(solver) thead-2 execute: class B: run service from JAR service in JAR: system.load(solver) ''' same solver path, same solver version, same solver package when executing thead-2, CPU-load average goes higher than 1, CPU-idle is ok, memory use is ok maybe you can try this to recur I've tried to use jstack to see what happend, but coredump came so fast. — Reply to this email directly, view it on GitHub <#4695 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3LS2QRYQVTFXGJW4JD3FOOBPAVCNFSM6AAAAAB7UY6UGSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJYGE4TGNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[CTH-launch]

some info from JVM error log:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb4ed80e570, pid=8711, tid=0x00007fb4560fb700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_201-b09) (build 1.8.0_201-b09)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [ld-linux-x86-64.so.2+0x9570]  check_match.9525+0x10
#
# Core dump written. Default location: /docker/opt/xxx/xxxx/core or core.8711
#
# If you would like to submit a bug report, please visit:
#   http://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.
#

---------------  T H R E A D  ---------------

Current thread (0x00007fb45667a400):  JavaThread "Rhino-bikeIntelliOrToolsConflictTestExecutorPool-2" daemon [_thread_in_native, id=9306, stack(0x00007fb4560bb000,0x00007fb4560fc000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000011ec4

Registers:
RAX=0x000000000000172e, RBX=0x00007fb4560f7d00, RCX=0x0000000041cf8143, RDX=0x00007fb452bbaa50
RSP=0x00007fb4560f7c90, RBP=0x0000000000011ec0, RSI=0x0000000000001ee8, RDI=0x0000000000011ec0
R8 =0x0000000000000002, R9 =0x0000000001073e05, R10=0x00007fb4560f7d00, R11=0x00007fb4560f7e00
R12=0x000000000000000a, R13=0x0000000041cf8142, R14=0x00007fb458e52418, R15=0x0000000000000000
RIP=0x00007fb4ed80e570, EFLAGS=0x0000000000010206, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007fb4560f7c90)
0x00007fb4560f7c90:   00007fb4560f8180 0000000000006550
0x00007fb4560f7ca0:   0000000000000000 000000000000000a
0x00007fb4560f7cb0:   0000000041cf8142 00007fb4ed80edbb
0x00007fb4560f7cc0:   00007fb4ed8222ab 00007fb4560f7d00
0x00007fb4560f7cd0:   00007fb452bbaa50 0000000001073e05
0x00007fb4560f7ce0:   00007fb4560f7e10 00007fb4560f7e00
0x00007fb4560f7cf0:   00007fb400000002 00007fb49d070630
0x00007fb4560f7d00:   0000000000000000 0000000000000000
0x00007fb4560f7d10:   00007fb458eb2000 00007fb45300a820
0x00007fb4560f7d20:   00000000000220a8 0000000000000000
0x00007fb4560f7d30:   0000000200000000 00000000000007ba
0x00007fb4560f7d40:   656e696665646e75 00007fb4560f7ef0
0x00007fb4560f7d50:   00007fb4560f7ea0 0000000000000000
0x00007fb4560f7d60:   0000000000000000 00007fb458eb2388
0x00007fb4560f7d70:   00007fb458eb2000 00007fb4ed80f09f
0x00007fb4560f7d80:   0000000000000000 0000000000000000
0x00007fb4560f7d90:   0000007200000002 0000000000000000
0x00007fb4560f7da0:   00007fb400000000 00007fb458eb2000
0x00007fb4560f7db0:   0000000000000000 0000000000010000
0x00007fb4560f7dc0:   00007fb4560f7d20 00007fb4ddb05769
0x00007fb4560f7dd0:   0000000000000000 00007fb458eb2388
0x00007fb4560f7de0:   00007fb4560f7e10 00007fb4560f7e00
0x00007fb4560f7df0:   0000000041cf8142 00007fb45300a820
0x00007fb4560f7e00:   00000000ffffffff 00007fb4560f7e40
0x00007fb4560f7e10:   0000000000000000 0000000000000000
0x00007fb4560f7e20:   00007fb4c1605d80 00007fb4eb30f357
0x00007fb4560f7e30:   00007fb4ed823cd0 00007fb45300a820
0x00007fb4560f7e40:   00007fb4ed821f5a 00007fb4ed821f5a
0x00007fb4560f7e50:   00007fb4ea8db2a0 0000003000000030
0x00007fb4560f7e60:   00007fb4560f7f30 00007fb4eb5c59f9
0x00007fb4560f7e70:   0000000000000002 00007fb4eda26c00
0x00007fb4560f7e80:   00007fb4eda27000 00007fb4ec061000 

Instructions: (pc=0x00007fb4ed80e570)
0x00007fb4ed80e550:   77 fd ff ff 66 2e 0f 1f 84 00 00 00 00 00 66 90
0x00007fb4ed80e560:   41 55 41 54 55 48 89 fd 53 4c 89 d3 48 83 ec 08
0x00007fb4ed80e570:   0f b6 47 04 83 e0 0f 48 83 7f 08 00 0f 84 10 01
0x00007fb4ed80e580:   00 00 31 d2 66 83 7d 06 00 0f 94 c2 85 53 3c 0f 

Register to memory mapping:

RAX=0x000000000000172e is an unknown value
RBX=0x00007fb4560f7d00 is pointing into the stack for thread: 0x00007fb45667a400
RCX=0x0000000041cf8143 is an unknown value
RDX=
[error occurred during error reporting (printing register info), id 0xb]

Stack: [0x00007fb4560bb000,0x00007fb4560fc000],  sp=0x00007fb4560f7c90,  free space=243k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [ld-linux-x86-64.so.2+0x9570]  check_match.9525+0x10

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 8432  java.lang.ClassLoader$NativeLibrary.find(Ljava/lang/String;)J (0 bytes) @ 0x00007fb4daa8dddc [0x00007fb4daa8dd80+0x5c]
j  java.lang.ClassLoader.findNative(Ljava/lang/ClassLoader;Ljava/lang/String;)J+49
v  ~StubRoutines::call_stub
j  com.google.ortools.linearsolver.mainJNI.MPSolver_createSolver(Ljava/lang/String;)J+0
j  com.google.ortools.linearsolver.MPSolver.createSolver(Ljava/lang/String;)Lcom/google/ortools/linearsolver/MPSolver;+5
j  xxx.xxxxxxx.xxxxx.xxx.utils.MPSolverUtils.buildSolver(Ljava/lang/String;ILcom/xxx/somepath/dispatch/entity/Instance;)Lcom/google/ortools/linearsolver/MPSolver;+42
j  xxx.xxxxxxx.xxxxx.xxx.alg.cg.OrderColumnGeneration.<init>(Lcom/xxx/somepath/dispatch/entity/Instance;)V+163
j  xxx.xxxxxxx.xxxxx.xxx.alg.cg.ColumnGeneration.<init>(Lcom/xxx/somepath/dispatch/entity/Instance;)V+53
j  xxx.xxxxxxx.xxxxx.xxx.service.strategy.DefaultStrategy.match(Lcom/xxx/somepath/dispatch/entity/Instance;)Lcom/xxx/somepath/dispatch/dto/ModelMatchRespDTO;+104
j  xxx.xxxxxxx.xxxxx.xxx.service.ModelMatchServiceImpl.generateOrders(Lcom/xxx/dsomepathdispatch/dto/ModelMatchReqDTO;)Ljava/util/List;+148
j  xxx.xxxxxxx.xxxxx.xxx.service.ModelMatchServiceImpl.modelMatch(Lcom/xxx/somepath/dispatch/dto/ModelMatchReqDTO;)Lcom/xxx/somepath/dispatch/dto/ModelMatchRespDTO;+39
j  xx.xx.xx.service.ThirdModelMatchServiceV2.lambda$testAlgoOrToolsLoadConflict$2(Ljava/util/concurrent/CountDownLatch;Ljava/util/concurrent/atomic/AtomicReference;Lcom/xxx/somepath/dto/ModelMatchReqDTO;)Lcom/xxx/somepath/dto/ModelMatchRespDTO;+53
j  xx.xx.xx.service.ThirdModelMatchServiceV2$$Lambda$675.call()Ljava/lang/Object;+16
j  abc.abc.abc.threadpool.RhinoWrapCallable.call()Ljava/lang/Object;+15
j  abc.abc.abc.threadpool.component.RhinoFutureTask.run()V+42
j  asdf.asdf.asdf.asdf.thread.CatTraceRunnable.run()V+16
j  fds.fds.fds.trace.thread.TraceRunnable.run()V+20
j  abc.abc.abc..threadpool.component.RhinoProfilingRunnable.run()V+8
J 18038 C1 java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (225 bytes) @ 0x00007fb4ddd0c724 [0x00007fb4ddd0b640+0x10e4]
j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5
J 17716 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007fb4ddc0aed4 [0x00007fb4ddc0ad80+0x154]
v  ~StubRoutines::call_stub

[lperron]

Unfortunately, it does not help, and this is not what I asked.

a few comments:

• the solver is not CP-SAT, but the linear solver, event if you use CP-SAT as a backend
• I want the output of the two solvers when running: linear_solver.enableOutput() and grapping the output on cout.
• maybe you can try to recompile the library in debug mode to understand where it crashes