I cannot discover why my integrations tests with objectify that are crashing.
There is no problem when is executed one by one or debuging.
That is the objectify code.
protected void before() throws Throwable {
original = ObjectifyService.factory();
ObjectifyFactory factory = newObjectifyFactory();
for (Class<?> type : register) {
factory.register(type);
}
ObjectifyService.setFactory(factory);
closeable = ObjectifyService.begin();
}
protected void after() {
ObjectifyService.setFactory(original);
closeable.close();
}
After some tests the runner stop and i receive this message.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000003, pid=15104, tid=9848
#
# JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000000003
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as: Compiled method (nm) 7403 625 n java.lang.Class::isInstance (native) total in heap [0x0000000002b4bf10,0x0000000002b4c2b8] = 936 relocation [0x0000000002b4c030,0x0000000002b4c088] = 88 main code [0x0000000002b4c0a0,0x0000000002b4c2b8] = 536 Compiled method (c2) 7404 752 java.lang.invoke.LambdaForm$NamedFunction::invoke_L_L (28 bytes) total in heap [0x0000000002c38490,0x0000000002c38778] = 744 relocation [enter image description here][1][0x0000000002c385b0,0x0000000002c385d0] = 32 main code [0x0000000002c385e0,0x0000000002c38660] = 128 stub code [0x0000000002c38660,0x0000000002c38698] = 56 oops [0x0000000002c38698,0x0000000002c386a0] = 8 scopes data [0x0000000002c386a0,0x0000000002c386e8] = 72 scopes pcs [0x0000000002c386e8,0x0000000002c38748] = 96 dependencies [0x0000000002c38748,0x0000000002c38750] = 8 handler table [0x0000000002c38750,0x0000000002c38768] = 24 nul chk table [0x0000000002c38768,0x0000000002c38778] = 16
Whatever you are seeing here is a JVM bug. This is not supposed to be possible. Make sure you have the most recent version of the JDK installed, and if so, the only place you can really file an issue is with Oracle :-(
Related
I'm using openjdk-11 running my application, bu the jvm frequent unexplained crash. The log mentioned that the method of BigDecimal.sqrt was called and crashed, but this method was not called in my code.
This is my code for getBetweenSeconds method in DateUtil：
public static long getBetweenSeconds(Date from, Date to) {
return Math.abs((to.getTime() - from.getTime()) / 1000);
}
Following is the full log file:
full log file
Following is the crash log:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007eff70883f62, pid=32037, tid=32143
#
# JRE version: OpenJDK Runtime Environment 18.9 (11.0.12+7) (build 11.0.12+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM 18.9 (11.0.12+7-LTS, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# j java.math.BigDecimal.sqrt(Ljava/math/MathContext;)Ljava/math/BigDecimal;+1 java.base#11.0.12
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/crown/service/core.32037)
#
# If you would like to submit a bug report, please visit:
# https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&component=java-11-openjdk
#
--------------- S U M M A R Y ------------
Command Line: -Xmx5120m -XX:MaxMetaspaceSize=200m -Dserver.port=9090 -Dwebsocket.port=9100 -Dserver.number=S001 -Dspring.profiles.active=prod -Dapplication.exchange=OKEX -Dapplication.get-ticker-info=false -Dlog4j2.formatMsgNoLookups=true /home/crown/service/crown-service-9090.jar
Host: Intel(R) Xeon(R) Platinum 8269CY CPU # 2.50GHz, 2 cores, 7G, Alibaba Cloud Linux release 3 (Soaring Falcon)
Time: Mon Feb 28 22:44:01 2022 CST elapsed time: 115.158780 seconds (0d 0h 1m 55s)
--------------- T H R E A D ---------------
Current thread (0x00007eff896e6800): JavaThread "RBT-SWAP-OKE-s3RXY" [_thread_in_Java, id=32143, stack(0x00007eff0edc9000,0x00007eff0eeca000)]
Stack: [0x00007eff0edc9000,0x00007eff0eeca000], sp=0x00007eff0eec8520, free space=1021k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
j java.math.BigDecimal.sqrt(Ljava/math/MathContext;)Ljava/math/BigDecimal;+1 java.base#11.0.12
j com.liuqi.utils.DateUtil.getBetweenSeconds(Ljava/util/Date;Ljava/util/Date;)J+5
j com.liuqi.robotruntime.robots.AbstractSWAPRobot.handleNewPrice(Lcom/liuqi/robotruntime/ContractOrder;Ljava/math/BigDecimal;Ljava/math/BigDecimal;Ljava/lang/String;Ljava/lang/String;)V+33
J 13459% c2 com.liuqi.robotruntime.robots.AbstractSWAPRobot.lambda$startExecute$2()V (524 bytes) # 0x00007eff78aebae8 [0x00007eff78ae8240+0x00000000000038a8]
j com.liuqi.robotruntime.robots.AbstractSWAPRobot$$Lambda$882.run()V+4
j java.lang.Thread.run()V+11 java.base#11.0.12
v ~StubRoutines::call_stub
V [libjvm.so+0x8c42a9] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x3b9
V [libjvm.so+0x8c268e] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x1ae
V [libjvm.so+0x97ce90] thread_entry(JavaThread*, Thread*)+0x80
V [libjvm.so+0xe8f428] JavaThread::thread_main_inner()+0x268
V [libjvm.so+0xe8a6df] Thread::call_run()+0x14f
V [libjvm.so+0xc68886] thread_native_entry(Thread*)+0xf6
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000017f40c9cbbe
Register to memory mapping:
RAX=0x0 is NULL
RBX=0x0000000000000014 is an unknown value
RCX=0x0000017f40c9cbb6 is an unknown value
RDX=0x0000000040000001 is an unknown value
RSP=0x00007eff0eec8520 is pointing into the stack for thread: 0x00007eff896e6800
RBP=0x00007eff0eec8578 is pointing into the stack for thread: 0x00007eff896e6800
RSI=0x00007eff896e73e0 points into unknown readable memory: 0x0000001e00000003 | 03 00 00 00 1e 00 00 00
RDI={method} {0x00000008000a5390} 'sqrt' '(Ljava/math/MathContext;)Ljava/math/BigDecimal;' in 'java/math/BigDecimal'
R8 =0x00007eff89bc34f0 points into unknown readable memory: 0x0000000800104280 | 80 42 10 00 08 00 00 00
R9 =0x0000000000000004 is an unknown value
R10=0x00007eff8fe9cfa0: <offset 0x0000000001317fa0> in /usr/lib/jvm/java-11-openjdk-11.0.12.0.7-0.1.al8.x86_64/lib/server/libjvm.so at 0x00007eff8eb85000
R11=0x00007eff70889780 is at code_begin+0 in an Interpreter codelet
deoptimization entry points [0x00007eff70889780, 0x00007eff7088b980] 8704 bytes
R12=0x0 is NULL
R13=0x00000008005fd029 is pointing into metadata
R14=0x00007eff0eec8620 is pointing into the stack for thread: 0x00007eff896e6800
R15=0x00007eff896e6800 is a thread
I am trying to do API benchmarking using JMH. An error occurred during the initialization of VM: Not sure what can I do to fix this one. Could you please take a look at the below console output.
# JMH version: 1.21
# VM version: JDK 1.8.0_275, OpenJDK 64-Bit Server VM, 25.275-b01
# VM invoker: /Users/vbais/.sdkman/candidates/java/8.0.275.hs-adpt/jre/bin/java
# VM options: -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dorg.gradle.native=false -agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=49776 -javaagent:build/tmp/expandedArchives/org.jacoco.agent-0.8.2.jar_56a88f9ce507637adfc797f83ef298ef/jacocoagent.jar=destfile=build/jacoco/test.exec,append=true,inclnolocationclasses=false,dumponexit=true,output=file,jmx=false -Dfile.encoding=UTF-8 -Duser.country=IN -Duser.language=en -Duser.variant -ea
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: ServiceCTest.extracted
# Run progress: 0.00% complete, ETA 00:03:20
# Fork: 1 of 2
Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager: worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager
at sun.misc.Launcher.<init>(Launcher.java:106)
at sun.misc.Launcher.<clinit>(Launcher.java:54)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1444)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1429)
<forked VM failed with exit code 1>
<stdout last='20 lines'>
Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager: worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager
at sun.misc.Launcher.<init>(Launcher.java:106)
at sun.misc.Launcher.<clinit>(Launcher.java:54)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1444)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1429)
The code which I am trying to benchmark:
#Test
public void trial() throws ParseException, InterruptedException, RunnerException {
Application app = TestUtil.application(4,5,3);
getOpsRest().postForObject(getInternalUrl() + "v1/Application", app,Application.class);
Options opt = new OptionsBuilder()
.include(".*")
.forks(2)
.build();
new Runner(opt).run();
}
#BenchmarkMode(Mode.AverageTime)
#Benchmark
public void extracted() {
LocalDateTime ldt = LocalDateTime.now().minusDays(30);
String lastEvaluateTime = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss", Locale.ENGLISH).format(ldt);
ResponseEntity<OrgExpiryInfo[]> a = getRest().getForEntity
(getUrl() + "/abc/'{lastEvaluateTime}'", OrgExpiryInfo[].class, lastEvaluateTime);
}
I receive the follow sporadic crash with JNA. Are there any JNA settings to prevent this?
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_FLT_DIVIDE_BY_ZERO (0xc000008e) at pc=0x0000000000b6ec60, pid=2364, tid=3908
#
# JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build 1.8.0_74-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# v ~RuntimeStub::unwind_exception Runtime1 stub
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# ....\hs_err_pid2364.log
Compiled method (c1) 425393 12999 ! 3 database.DatabaseUtils::executeQuery (83 bytes)
total in heap [0x00000000028d1350,0x00000000028d2e98] = 6984
relocation [0x00000000028d1470,0x00000000028d15b0] = 320
main code [0x00000000028d15c0,0x00000000028d26a0] = 4320
stub code [0x00000000028d26a0,0x00000000028d27a8] = 264
oops [0x00000000028d27a8,0x00000000028d27b8] = 16
metadata [0x00000000028d27b8,0x00000000028d2818] = 96
scopes data [0x00000000028d2818,0x00000000028d2bf0] = 984
scopes pcs [0x00000000028d2bf0,0x00000000028d2e20] = 560
dependencies [0x00000000028d2e20,0x00000000028d2e28] = 8
handler table [0x00000000028d2e28,0x00000000028d2e58] = 48
nul chk table [0x00000000028d2e58,0x00000000028d2e98] = 64
Compiled method (c1) 425394 12999 ! 3 database.DatabaseUtils::executeQuery (83 bytes)
total in heap [0x00000000028d1350,0x00000000028d2e98] = 6984
relocation [0x00000000028d1470,0x00000000028d15b0] = 320
main code [0x00000000028d15c0,0x00000000028d26a0] = 4320
stub code [0x00000000028d26a0,0x00000000028d27a8] = 264
oops [0x00000000028d27a8,0x00000000028d27b8] = 16
metadata [0x00000000028d27b8,0x00000000028d2818] = 96
scopes data [0x00000000028d2818,0x00000000028d2bf0] = 984
scopes pcs [0x00000000028d2bf0,0x00000000028d2e20] = 560
dependencies [0x00000000028d2e20,0x00000000028d2e28] = 8
handler table [0x00000000028d2e28,0x00000000028d2e58] = 48
nul chk table [0x00000000028d2e58,0x00000000028d2e98] = 64
Compiled method (c1) 425394 12999 ! 3 database.DatabaseUtils::executeQuery (83 bytes)
total in heap [0x00000000028d1350,0x00000000028d2e98] = 6984
relocation [0x00000000028d1470,0x00000000028d15b0] = 320
main code [0x00000000028d15c0,0x00000000028d26a0] = 4320
stub code [0x00000000028d26a0,0x00000000028d27a8] = 264
oops [0x00000000028d27a8,0x00000000028d27b8] = 16
metadata [0x00000000028d27b8,0x00000000028d2818] = 96
scopes data [0x00000000028d2818,0x00000000028d2bf0] = 984
scopes pcs [0x00000000028d2bf0,0x00000000028d2e20] = 560
dependencies [0x00000000028d2e20,0x00000000028d2e28] = 8
handler table [0x00000000028d2e28,0x00000000028d2e58] = 48
nul chk table [0x00000000028d2e58,0x00000000028d2e98] = 64
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
In my Java application I want to capture SIGINTs, do some pre-processing, and then let the default behavior (process termination) run. I would think I could do something like this:
Signal.handle(new Signal("INT"), new SignalHandler() {
#Override
public void handle(Signal signal) {
// preprocessing
// ...
// now do default behavior
SignalHandler.SIG_DFL.handle(signal);
}
});
However when I send at SIGINT to this application, I get a SEGV:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000000000000, pid=10261, tid=21507
#
# JRE version: Java(TM) SE Runtime Environment (8.0_51-b16) (build 1.8.0_51-b16)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000000000
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /private/tmp/hs_err_pid10261.log
#
# 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.
#
Abort trap: 6
It seems SignalHandler.SIG_DFL is not meant to be called directly (even from other signal handling code). So how can I manually trigger it?
Alternatively, how can I manually replicate the behavior of SIG_DFL? It appears to be equivalent to:
System.exit(signal.getNumber() + 128)
but I don't see any documentation to that effect.
Another way to phrase my question:
In practice* is there a difference between these two code blocks?
A)
Signal.handle(new Signal("INT"), SignalHandler.SIG_DFL);
B)
Signal.handle(new Signal("INT"), new SignalHandler() {
#Override
public void handle(Signal signal) {
System.exit(signal.getNumber() + 128)
}});
*I know undocumented behavior could change at any time, but it's unlikely that the JVM's exit behavior will change mid-version. An answer that simply details what happens now is acceptable, in practice.
I think the key to the mystery here is that SIG_DFL is not the original handler for SIGINT.
The following code worked for me:
Signal sigInt = new Signal("INT");
// First register with SIG_DFL, just to get the old handler.
final SignalHandler oldHandler = Signal.handle(sigInt, SignalHandler.SIG_DFL );
// Now register the actual handler
Signal.handle(sigInt, new SignalHandler(){
#Override
public void handle(Signal signal) {
System.err.println("Sigint is being handled");
oldHandler.handle(signal);
}
});
This does not cause the segmentation violation, and instead terminates the program as expected (after printing the sample text).
Credit for originally noticing this goes to RealSkeptic, but I wanted to expand on it in an answer.
The default behavior for SIGINT, SIGTERM, and SIGHUP is not, in fact, SignalHandler.SIG_DFL. Instead, the java.lang.Terminator class registers a SignalHandler that simply calls Shutdown.exit():
SignalHandler sh = new SignalHandler() {
public void handle(Signal sig) {
Shutdown.exit(sig.getNumber() + 0200);
}
};
You can capture this SignalHandler by calling Signal.handle() (since it returns the old handler), or you can simply define your own handler that calls System.exit() which will do the same thing.
Note that Terminator's call to Shutdown.exit() is not exactly the same as System.exit(). The former is package-private, meaning you can't call it directly. If a security manager prevents you from calling System.exit(), you'll have to capture the original handler and reuse it.
Warning: this is undocumented behavior. It's unlikely but entirely possible that future releases of Java could change this behavior.
Exiting with 128+signal number seems to be typical on Unix/Linux.
Are there any standard exit status codes in Linux?
For more evidence, see also:
http://journal.thobe.org/2013/02/jvms-and-kill-signals.html
Browsing the source code on OpenJDK suggests that the default behaviour is to allow the underlying C Runtime or OS default action to proceed.
In any case this is only typical behaviour, and as you point out is not documented. Exit codes are not standardized - generally there is a convention that zero means success, and nonzero failure, but even the first part is not always adhered to. Therefore it is for you to define your own exit codes.
I am trying to connect to a local DB that I created in SQL sever 2008 but Ihave tried everything but the same error comes up, I am conected in Database explorer but need to be connected to the DB from my app for Register pages and login. This is my error:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (classFileParser.cpp:3470), pid=5644, tid=5492
# Error: ShouldNotReachHere()
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode windows-amd64 compressed oops)
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\christiej\workspace\MainActivity\hs_err_pid5644.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
Here is my code:
public class Example
{
public static void main (String[] args) throws SQLException, ClassNotFoundException{
Class.forName("com.sqlserver.jdbc.Driver"); // Setup the connection with the DB
Connection connect = DriverManager.getConnection("jdbc:sqlserver://192.168.0.13:1433/Risk_ProfilingV2","sa","Dsolve01#");
// Statements allow to issue SQL queries to the database
java.sql.Statement statement = connect.createStatement();
// Result set get the result of the SQL query
ResultSet resultSet = null;
try {
resultSet = statement.executeQuery("select * from User_Table");
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
while (resultSet.next()) { //retrieve data
String data = resultSet.getString("User_Name");
}
}
}
this similar queestion has a useful-looking answer :
Fatal error by Java runtime environment
which points to this page :
http://dtmilano.blogspot.com/2008/11/android-testing-on-android-platform.html