Hi Avik,
It looks it is still an issue because version 1_6 is still asserted in
JavaCall.init?
If I disable that assert, on linux I am able to run your examples on the
doc page and Pkg.test("JavaCall") completes successfully against
java-8-oracle. Probably doesn't help much, but there is a datapoint on a
different OS for you.
Some random debugging ideas
- valgrind's gdbserver can be very useful for general debugging in
situations when gdb can't otherwise trap or follow threads reliably.
- could try calling JNI_CreateJavaVM in a C shared library invoked from
Julia
- try this from a Julia built with LLVM_VER=svn ... You might get decent
backtraces from the pure-Julia code (or maybe not at all? I do on linux,
but there were some issues with backtraces on OS X and I am not sure if
they have been resolved).
Isaiah
On Sat, Nov 29, 2014 at 6:02 PM, Avik Sengupta <[email protected]>
wrote:
> Thanks Isaiah, that helps. Your hints have made be debug further into
> this.
>
> The bad news however is that the exception is thrown in some hand coded
> assembly that seems to do CPU detection... in some code that looks like
> this (though probably not exactly that) :
> http://hg.openjdk.java.net/hsx/hsx25/hotspot/file/0c94c41dcd70/src/cpu/x86/vm/vm_version_x86.cpp#l95
>
> I presume the truncated backtrace is due to jumping into assembly.. The
> backtrace dissapears in lldb as soon as execution goes into the hand
> generated assembly.
>
> I've confirmed that raw C code calling this function works correctly.
> Also, this section of the code, and its callers, do not take any
> parameters, so it is unlikely that the Julia to C translation of the
> parameters are at fault. So yeah, stumped :(
>
>
> On Saturday, 29 November 2014 17:45:15 UTC, Isaiah wrote:
>>
>> You can see where the SEGV handler is set up in init.c (see
>> mach_segv_listener).
>> It might also be useful to set a break in the "create" function on the
>> JVM C API side, and step through from there.
>>
>>
>>
