[DiSL-user] JVM Crash

Thu May 4 13:34:02 CEST 2017

Great Lubomir, 

I’ll checkout the new version later. In the meanwhile, I can confirm that with the trunk version and your patches also the JVM crash on Mac vanished !

Thanks !

— Alessio

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

> On 04 May 2017, at 11:50, Lubomír Bulej <lubomir.bulej at d3s.mff.cuni.cz> wrote:
> 
> Hi Alessio,
> 
> just to let you know, I have made some changes to the trunk that should
> resolve the compilation issues on Mac for now, before I can move to a solution
> that can properly accommodate different platforms and different compilers.
> 
> This should leave us "only" with JVM/analysis issues, but we should be able to
> test them on the trunk version.
> 
> 
> Lubomir
> 
> On 04/05/17 10:07, Lubomír Bulej 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>
>>> 
> 
> -- 
> Dept. Dist. and Dependable Systems
> Faculty of Mathematics and Physics
> Charles University, Czech Republic
> Web: http://d3s.mff.cuni.cz <http://d3s.mff.cuni.cz/>
> Tel: +420-221914267

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/disl-user/attachments/20170504/47cf8453/attachment.html>