JuliaInterop / JavaCall.jl

Call Java from Julia
http://juliainterop.github.io/JavaCall.jl
Other
118 stars 53 forks source link

union would crash after init #94

Open clouds56 opened 5 years ago

clouds56 commented 5 years ago

after using JavaCall; JavaCall.init() the following code would crash

union([1 for a in 1:1000]...)

(after using JavaCall and before JavaCall.init() won't)

linux 4.19.2 julia version 1.0.1 JavaCall v0.7.1

ldd julia:

    linux-vdso.so.1
    libjulia.so.1 => /usr/bin/../lib/libjulia.so.1
    libdl.so.2 => /usr/bin/../lib/libdl.so.2
    librt.so.1 => /usr/bin/../lib/librt.so.1
    libpthread.so.0 => /usr/bin/../lib/libpthread.so.0
    libc.so.6 => /usr/bin/../lib/libc.so.6
    libLLVM-6.0.so => /usr/bin/../lib/julia/libLLVM-6.0.so
    libstdc++.so.6 => /usr/bin/../lib/julia/libstdc++.so.6
    libm.so.6 => /usr/bin/../lib/libm.so.6
    libgcc_s.so.1 => /usr/bin/../lib/julia/libgcc_s.so.1
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
aviks commented 5 years ago

Do you get a segfault? Is there a stacktrace? I cannot replicate this on Julia 1.0.0 on Mac OS

clouds56 commented 5 years ago

There do have core dumped, but bt doesn't work.

(gdb) bt

0 0x00007f2cbed0f1c9 in ?? ()

Backtrace stopped: Cannot access memory at address 0x7ffcc68a7a10

I've tried valgrind julia -e "using JavaCall; JavaCall.init(); union([1 for i in 1:1000]...)" and it says lots of stuff like this

==25226== Warning: set address range perms: large range [0x705200000, 0x800000000) (noaccess) ==25226== Warning: set address range perms: large range [0x800000000, 0x840000000) (noaccess) ==25226== Invalid write of size 4 ==25226== at 0x3C65276D: ??? ==25226== by 0x3C644848: ??? ==25226== by 0x333B6971: ??? (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x33391678: ??? (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x33391AC0: ??? (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x3339195E: ??? (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x338C01FE: ??? (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x338C13CD: ??? (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x33438AF0: JNI_CreateJavaVM (in /usr/lib/jvm/java-11-openjdk/lib/server/libjvm.so) ==25226== by 0x30B26A2F: ??? ==25226== by 0x488A0FB: jl_fptr_trampoline (gf.c:1831) ==25226== by 0x488E175: jl_apply_generic (gf.c:2184) ==25226== Address 0x1ffeffcbf8 is on thread 1's stack ==25226== 4096 bytes below stack pointer

(almost, not checked one by one) all of them occurs inside libjvm.so and then

==25226== Can't extend stack to 0x1ffef039d8 during signal delivery for thread 1: ==25226== too small or bad protection modes ==25226== ==25226== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==25226== Access not within mapped region at address 0x1FFEF039D8 ==25226== at 0x48F91C9: jl_apply_2va (rtutils.c:286) ==25226== If you believe this happened as a result of a stack ==25226== overflow in your program's main thread (unlikely but ==25226== possible), you can try to increase the size of the ==25226== main thread stack using the --main-stacksize= flag. ==25226== The main thread stack size used in this run was 8388608. ==25226== ==25226== Process terminating with default action of signal 11 (SIGSEGV) ==25226== Bad permissions for mapped region at address 0x1FFEF04898 ==25226== at 0x482D120: _vgnU_freeres (vg_preloaded.c:59) ==25226== ==25226== HEAP SUMMARY: ==25226== in use at exit: 54,374,330 bytes in 56,255 blocks ==25226== total heap usage: 789,296 allocs, 733,041 frees, 167,145,401 bytes allocated ==25226== ==25226== LEAK SUMMARY: ==25226== definitely lost: 6,900 bytes in 2,823 blocks ==25226== indirectly lost: 0 bytes in 0 blocks ==25226== possibly lost: 509,812 bytes in 3,094 blocks ==25226== still reachable: 53,857,618 bytes in 50,338 blocks ==25226== of which reachable via heuristic: ==25226== newarray : 43,752 bytes in 9 blocks ==25226== multipleinheritance: 4,432 bytes in 7 blocks ==25226== suppressed: 0 bytes in 0 blocks ==25226== Rerun with --leak-check=full to see details of leaked memory ==25226== ==25226== For counts of detected and suppressed errors, rerun with: -v ==25226== Use --track-origins=yes to see where uninitialised values come from ==25226== ERROR SUMMARY: 1746969 errors from 693 contexts (suppressed: 20 from 4)

I'm not sure if it helps. If need any other information, instructions are welcome.

BTW, my java version goes OpenJDK 64-Bit Server VM (build 11.0.1+13, mixed mode).

mkitti commented 4 years ago

I cannot replicate this on Linux.