[DiSL-user] JVM Crash

Thu May 4 11:49:00 CEST 2017

Hi Lubomir,

applied the patch, observed expected test failing but fixed the OnLoad error for the agent

Thanks 

— Alessio

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

> On 04 May 2017, at 10:07, Lubomír Bulej <lubomir.bulej at d3s.mff.cuni.cz> wrote:
> 
> Hi Alessio,
> 
> the compilation on Mac is still somehow broken due to way how clang handles
> some of the options differently than GCC.
> 
> I use the -fvisibility=hidden option with GCC to make most of the symbols
> hidden except for those that are explicitly marked as visible. Apparently,
> this does not work on clang, because it does not know the "externally_visible"
> attribute, but understands the -fvisibility=hidden option, which means that it
> will hide the Agent_OnLoad library entry point required by the JVM.
> 
> So please do one more change (or apply the attached patch) to the
> src-disl-agent/Makefile, which is to comment out the line with the following
> content:
> 
> CFLAGS_PARTS += -fvisibility=hidden
> 
> 
> That should let you run "ant test" and get "expected" results.
> 
> By "expected" I mean the 2-VM tests which only use DiSL server should always
> succeed, while some of the 3-VM tests which use DiSL and ShadowVM servers may
> fail spuriously. They do produce correct results, but there seems to be some
> timing issue in the test harness which launches all the VMs and waits for them
> to finish before proclaiming a test a success.
> 
> It's on my TODO to look into these spurious failures, but there were usually
> more pressing matters to attend to :-)
> 
> 
> BTW, if you run with -Dtest.debug=true, you will get the command lines that
> the harness uses to execute all the VMs -- these can be then executed manually
> by just cut'n'pasting the commands into multiple terminal windows.
> 
> Also, -Dtest.verbose=true will keep the output of the Vms around in separate
> files for output and error streams for each (client|server|shadow) VM.
> You can also use -Dtest.name=<testname> to run only a particular test.
> 
> 
> 
> Lubomir
> 
> On 03/05/17 20:26, Alessio Gambi wrote:
>> 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>
>> 
> <Makefile.patch>