[DiSL-user] JVM Crash

[Alessio Gambi]

Hi Lubomir, 

I start to suspect that the JVM on the Mac might be broken. 

I updated to the latest version:

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

But still JVM crashes… On the good side, I checked out trunk and repeated the same experiment on a Linux VM.
This time, both compilation that execution went smooth.

Not sure how to proceed 

Best

— Alessio


Alessio Gambi, Ph.D.
gambi at st.cs.uni-saarland.de


> On 03 May 2017, at 10:55, Lubomír Bulej <lubomir.bulej at d3s.mff.cuni.cz> wrote:
> 
> Hi Alessio,
> 
> what we usually do when we manage to crash the JVM is introduce global
> exclusion list to limit the scope of instrumentation. For example, in ShadowVM
> version of Elephant Tracks, I had an initial exclusion like this:
> 
> java.lang.*.*
> java.security.*.*
> java.util.*.*
> 
> sun.misc.*.*
> sun.reflect.*.*
> 
> 
> Later I refined refined java.lang.*.* into
> 
> java.lang.Class.*
> java.lang.ClassLoader.*
> java.lang.Thread.*
> java.lang.String.*
> java.lang.System.*
> 
> java.lang.instrument.*.*
> java.lang.invoke.*.*
> java.lang.reflect.*.*
> java.lang.ref.*.*
> 
> 
> I didn't get to the other packages yet :-)
> 
> 
> The global exclusion list is given to DiSL as a path to file using the
> disl.exclusionList property.
> 
> 
> BTW, when running ShadowVM (or plain DiSL, for that matter) I rarely use the
> disl.py launcher. Instead, I'm using a script like the one I'm attaching,
> because I want to be able to see what is going on.
> 
> It may use some of the features from the trunk version to determine when a
> server has started. Also, it will not be directly portable to Mac, because it
> for example expects dynamic libraries to have an .so suffix, but you'll get
> the idea and maybe adapt it your needs.
> 
> You will also notice that I'm running the instrumentation without bypass,
> which requires that the instrumentation does not really use the class library
> and only calls into the REDispatch class.
> 
> 
> Best regards,
> Lubomir
> 
> On 03/05/17 08:07, Alessio Gambi wrote:
>> Hi Lubomir,
>> 
>> I split the original message in two threads
>> 
>>> Regarding the crash -- are you instrumenting anything in the Java Class Library?
>> 
>> Yes, I do. 
>> 
>> Is there any additional thing that I can try out on my own to rule out possible root causes?
>> 
>> For example, some deeper logging/debugging, disabling/enabling DiSL options, 
>> restrict the scope of instrumentation, define additional guards, etc…
>> 
>> Best
>> 
>> — Alessio
>> 
>> 
>>> 
>>> But let's fix the compilation problem first and re-test on the trunk.
>>> 
>>> 
>>> Best regards,
>>> Lubomir
>>> 
>>> 
>>> 
>>> On 28/04/17 20:43, Alessio Gambi wrote:
>>>> Dear DiSL-ers,
>>>> 
>>>> while running a basic dynamic analysis using DiSL 2.1 (release) I stumbled upon a bad crash of the JVM [1].
>>>> 
>>>> I have no idea of what’s going on, and how I can fix this.
>>>> 
>>>> I can share the logs/dumps upon request.
>>>> 
>>>> Here my configuration [2] (taken from the  hs_err_pid file)
>>>> 
>>>> Any help is appreciated …
>>>> 
>>>> Thanks
>>>> 
>>>> Best
>>>> 
>>>> — Alessio
>>>> 
>>>> PS: I tried but failed to build DiSL from trunk ...
>>>> 	
>>>> 
>>>> [1]
>>>>    [exec] # A fatal error has been detected by the Java Runtime Environment:
>>>>    [exec] #
>>>>    [exec] #  SIGSEGV (0xb) at pc=0x00007fff9af03f72, pid=1802, tid=4867
>>>>    [exec] #
>>>>    [exec] # JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27)
>>>>    [exec] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode bsd-amd64 compressed oops)
>>>>    [exec] # Problematic frame:
>>>>    [exec] # C  [libsystem_c.dylib+0xf72]  strlen+0x12
>>>>    [exec] #
>>>>    [exec] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>>>>    [exec] #
>>>> 
>>>> 
>>>> [2] ---------------  S Y S T E M  ---------------
>>>> 
>>>> OS:Bsduname:Darwin 14.5.0 Darwin Kernel Version 14.5.0: Fri Feb 17 10:33:20 PST 2017; root:xnu-2782.50.9.1.1~1/RELEASE_X86_64 x86_64
>>>> rlimit: STACK 8192k, CORE 0k, NPROC 709, NOFILE 10240, AS infinity
>>>> load average:1.38 1.22 0.68
>>>> 
>>>> CPU:total 8 (4 cores per cpu, 2 threads per core) family 6 model 70 stepping 1, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, lzcnt, ht, tsc, tscinvbit, bmi1, bmi2
>>>> 
>>>> Memory: 4k page, physical 16777216k(3479728k free)
>>>> 
>>>> /proc/meminfo:
>>>> 
>>>> 
>>>> vm_info: Java HotSpot(TM) 64-Bit Server VM (25.60-b23) for bsd-amd64 JRE (1.8.0_60-b27), built on Aug  4 2015 10:47:24 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
>>>> 
>>>> time: Fri Apr 28 20:40:58 2017
>>>> elapsed time: 2 seconds (0d 0h 0m 2s)
>>>> 
> <etjava.txt>