I am running windows 10 with the Corttello 11 JVM. (I am finding the same behavior with OpenJDK 9-12, but 8 does not seem to experience this behavior)
Eclipse Version: 2019-09 R (4.13.0)
I have Spring Tools 4, Buildship Gradle Integration 3.0, and ANSI Escape in Console. I uninstalled all other plugins.
While ANSI Escape in Console is enabled, there is strange and unpredictable JVM faults when trying to start up a spring boot application from the "Boot Dashboard."
I have crafted a minimal project that exhibits this behavior. The JVM fault behavior changes based on library dependencies and parameters passed in. More often than not a "EXCEPTION_ACCESS_VIOLATION" occurs (or it will just not log anything and terminate immediately without printing anything)
test-microservice-2.zip
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffef06b4b39, pid=25688, tid=29644
#
# JRE version: OpenJDK Runtime Environment (11.0.5+10) (build 11.0.5+10-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.5+10-LTS, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# V [jvm.dll+0x664b39]
#
# 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\default\eclipse-workspaces\test\test-microservice-2\hs_err_pid25688.log
While the gradle boot project will not start, it should at least print out the "Spring" banner.
For the VM arguments in starting up the application use the following. The -Dj= variables don't actually do anything but does cause the fault to occur. When dummy arguments are removed on my system, the fault does not occur. If any of the dependent libraries are removed, the JVM fault also does not occur. The behavior seems pretty reliable on my system that it will fail, however, with other applications the behavior was less predictable.
I am running windows 10 with the Corttello 11 JVM. (I am finding the same behavior with OpenJDK 9-12, but 8 does not seem to experience this behavior) Eclipse Version: 2019-09 R (4.13.0)
I have Spring Tools 4, Buildship Gradle Integration 3.0, and ANSI Escape in Console. I uninstalled all other plugins.
While ANSI Escape in Console is enabled, there is strange and unpredictable JVM faults when trying to start up a spring boot application from the "Boot Dashboard."
I have crafted a minimal project that exhibits this behavior. The JVM fault behavior changes based on library dependencies and parameters passed in. More often than not a "EXCEPTION_ACCESS_VIOLATION" occurs (or it will just not log anything and terminate immediately without printing anything) test-microservice-2.zip
While the gradle boot project will not start, it should at least print out the "Spring" banner.
For the VM arguments in starting up the application use the following. The -Dj= variables don't actually do anything but does cause the fault to occur. When dummy arguments are removed on my system, the fault does not occur. If any of the dependent libraries are removed, the JVM fault also does not occur. The behavior seems pretty reliable on my system that it will fail, however, with other applications the behavior was less predictable.
-ea -Dendpoint.underDevelopment.allow=true -Dnope.routing.host=http://localhost:8080 -Dspring.cloud.config.uri=http://localhost:8888 -Dspring.cloud.config.failFast=true -Dspring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect -Dlogging.level.org.hibernate.SQL=debug -Dlogging.level.org.hibernate.type.descriptor.sql=trace -Dspring.profiles.active=aaa,bbb,ccc,ddd -Dnope.publishing.host=www.google.com -Dnope.search.host=www.google.com -Dspring.rabbitmq.addresses=localhost:5672 -Dspring.rabbitmq.username=XXXXX -Dspring.rabbitmq.password=***** -Dendpoints.shutdown.enabled=true -Deureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/ -Dj17=17 -Dj18=18 -Dj19=19 -Dj20=20 -Dj21=21 -Dj22=22 -Dj23=23 -Dj24=24 -Dj25=25 -Dj26=26 -Dj27=27 -Dj28=28 -Dj29=29 -Dj30=30 -Dj31=31 -Dj32=32 -Dj33=33 -Dj34=34 -Dj35=35 -Dj36=36 -Dj37=37 -Dj38=38 -Dj39=39 -Dj40=40 -Dj41=41 -Dj42=42 -Dj43=43 -Dj44=44 -Dj45=45 -Dj46=46 -Dj47=47 -Dj48=48 -Dj49=49 -Dj50=50 -Dj51=51 -Dj52=52 -Dj53=53 -Dj54=54 -Dj55=55 -Dj56=56 -Dj57=57 -Dj58=58 -Dj59=59 -Dj60=60 -Dj61=61 -Dj62=62 -Dj63=63 -Dj64=64 -Dj65=65 -Dj66=66 -Dj67=67 -Dj68=68 -Dj69=69 -Dj70=70 -Dj71=71 -Dj72=72 -Dj73=73 -Dj74=74 -Dj75=75 -Dj76=76 -Dj77=77 -Dj78=78 -Dj79=79 -Dj80=80 -Dj81=81 -Dj82=82 -Dj83=83 -Dj84=84 -Dj85=85 -Dj86=86 -Dj87=87 -Dj88=88 -Dj89=89 -Dj90=90 -Dj91=91 -Dj92=92 -Dj93=93 -Dj94=94 -Dj95=95 -Dj96=96 -Dj97=97 -Dj98=98 -Dj99=99When ANSI Escape in Console is disabled, the JVM fault does not occur.