[DiSL-user] JVM Crash

Thu May 4 10:07:44 CEST 2017

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>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.patch
Type: text/x-patch
Size: 391 bytes
Desc: not available
URL: <http://d3s.mff.cuni.cz/pipermail/disl-user/attachments/20170504/fb0e59a7/attachment.bin>