I confirmed that it crashes on multiple Debian 9 machines but it doesn't crash on Ubuntu 16.04. This behavior is consistent regardless of the JDK used (I tried openjdk 8, oracle 8 and openjdk 9). I am at a loss for how to track it down further due to the (apparent) GDB bug.
On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell <josh...@ualberta.ca> wrote: > No, it segfaults. > > On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda <va...@apache.org> wrote: >> >>> On Jul 5, 2017, at 22:16, Joshua Campbell <josh...@ualberta.ca> wrote: >>> >>> It's occuring after JCC calls JNI_CreateJavaVM >>> >>> cpp.py(529): env = initVM(os.pathsep.join(classpath) or None, >>> **initvm_args) >>> ^^^^^ last python trace before death >>> >>> Breakpoint 5, initVM (self=0x7ffff7e05048, args=0x7ffff66deac8, >>> kwds=0x7ffff7e00ec8) at jcc3/sources/jcc.cpp:527 >>> 527 if (JNI_CreateJavaVM(&vm, (void **) &vm_env, &vm_args) < 0) >>> ^^^^ last line of jcc.cpp before death >>> >>> (gdb) step >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x00007fffe43942b4 in ?? () >>> (gdb) >>> >>> >>> AFTER fixing debians debugging symbols with ln -s >>> /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64 >>> /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64 >>> >>> Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffffffc420, penv=0x7fffffffc418, >>> args=0x7fffffffc450) at ./src/hotspot/src/share/vm/prims/jni.cpp:5161 >>> 5161 ./src/hotspot/src/share/vm/prims/jni.cpp: No such file or directory. >>> (gdb) s >>> JNI_CreateJavaVM (vm=0x7fffffffc420, penv=0x7fffffffc418, >>> args=0x7fffffffc450) >>> at ./src/hotspot/src/share/vm/prims/jni.cpp:5163 >>> 5163 in ./src/hotspot/src/share/vm/prims/jni.cpp >>> (gdb) >>> /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error: >>> void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion >>> `frame_id_p (*this_id)' failed. >>> A problem internal to GDB has been detected, >>> further debugging may prove unreliable. >>> Quit this debugging session? (y or n) n >>> >>> This is a bug, please report it. For instructions, see: >>> <http://www.gnu.org/software/gdb/bugs/>. >>> >>> What in the name of heck >> >> Does it run without gdb ? >> >> Andi.. >> >>> >>> On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell <josh...@ualberta.ca> >>> wrote: >>>>> But you should get a better stacktrace ? >>>> >>>> I got the exact same stacktrace. >>>> >>>> $ ldd >>>> venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so >>>> linux-vdso.so.1 (0x00007ffcf4eb8000) >>>> libjava.so => >>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so >>>> (0x00007f412227f000) >>>> libjvm.so => >>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so >>>> (0x00007f412133d000) >>>> libpython3.5m.so.1.0 => >>>> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x00007f4120c3a000) >>>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >>>> (0x00007f41208b8000) >>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f41205b4000) >>>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 >>>> (0x00007f412039b000) >>>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 >>>> (0x00007f412017e000) >>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f411fddf000) >>>> libverify.so => >>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so >>>> (0x00007f411fbce000) >>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f411f9ca000) >>>> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 >>>> (0x00007f411f7a0000) >>>> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f411f584000) >>>> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 >>>> (0x00007f411f381000) >>>> /lib64/ld-linux-x86-64.so.2 (0x000055857b9dd000) >>>> >>>> I did verify it's compiling with -g >>>> >>>> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall >>>> -Wstrict-prototypes -g >>>> -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=. >>>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time >>>> -D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0" >>>> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include >>>> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3 >>>> -Ijcc3/sources >>>> -I/usr/include/python3.5m >>>> -I/home/joshua/unnaturalcode/venv3/include/python3.5m -c >>>> _jcc3/java/lang/String.cpp -o >>>> build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON >>>> -fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG >>>> >>>> But it's still producing >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> 0x00007fffe47eb2b4 in ?? () >>>> (gdb) bt >>>> #0 0x00007fffe47eb2b4 in ?? () >>>> #1 0x0000000000000246 in ?? () >>>> #2 0x00007fffe47eb160 in ?? () >>>> #3 0x00007fffffffc840 in ?? () >>>> #4 0x00007fffffffc7e0 in ?? () >>>> #5 0x00007ffff6006075 in VM_Version::get_processor_features() () >>>> from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so >>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >>>> >>>> >>>> >>>> >>>>> On Wed, Jul 5, 2017 at 11:38 AM, Andi Vajda <va...@apache.org> wrote: >>>>> >>>>> >>>>> On Jul 5, 2017, at 18:56, Joshua Campbell <josh...@ualberta.ca> wrote: >>>>> >>>>>>> What version if java is this jcc built with ? >>>>>>> To build jcc for debugging with gcc add --debug to the build command. >>>>>>> You >>>>>> should then have symbols visible to gdb. >>>>>> >>>>>> You mean with setup.py build --debug ? I tried that on trunk and got the >>>>>> same result. >>>>> >>>>> But you should get a better stacktrace ? >>>>> >>>>>>> Is the version of java used here the same as during jcc build time ? >>>>>> >>>>>> Yes I made sure of that and uninstalled all but openjdk and rebuilt. >>>>> >>>>> Did you verify this via running 'ldd' on the shared libraries involved ? >>>>> >>>>> That being said, it could be something different of course ! >>>>> >>>>> Andi.. >>>>> >>>>>> >>>>>>> On Wed, Jul 5, 2017 at 10:46 AM, Andi Vajda <va...@apache.org> wrote: >>>>>>> >>>>>>> >>>>>>>> On Jul 5, 2017, at 18:25, Joshua Campbell <josh...@ualberta.ca> wrote: >>>>>>>> >>>>>>>> This segfault appears to occur within the JVM code on both >>>>>>> oracle-java8-jdk >>>>>>>> and >>>>>>>> java-1.8.0-openjdk-amd64. I installed the JVM debugging symbols but it >>>>>>>> didn't seem to help. >>>>>>>> >>>>>>>> Occurs under python 2 and 3. I don't know how to debug this any >>>>>>>> further. >>>>>>>> >>>>>>>> 0 joshua@buttercup unnaturalcode 17609$ python3 -m virtualenv -p >>>>>>>> python3 >>>>>>>> venv3 Already using interpreter /usr/bin/python3 >>>>>>>> Using base prefix '/usr' >>>>>>>> New python executable in /home/joshua/unnaturalcode/venv3/bin/python3 >>>>>>>> Also creating executable in >>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python >>>>>>>> Installing setuptools, pkg_resources, pip, wheel...done. >>>>>>>> 0 joshua@buttercup unnaturalcode 17610$ source venv3/bin/activate >>>>>>>> 0 joshua@buttercup unnaturalcode 17611$ which python >>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python >>>>>>>> 0 joshua@buttercup unnaturalcode 17616$ pip install jcc --no-cache-dir >>>>>>>> Collecting jcc >>>>>>>> Downloading JCC-3.0.tar.gz (176kB) >>>>>>>> 100% |████████████████████████████████| 184kB 3.4MB/s >>>>>>>> Installing collected packages: jcc >>>>>>>> Running setup.py install for jcc ... done >>>>>>> >>>>>>> What version if java is this jcc built with ? >>>>>>> To build jcc for debugging with gcc add --debug to the build command. >>>>>>> You >>>>>>> should then have symbols visible to gdb. >>>>>>> >>>>>>>> Successfully installed jcc-3.0 >>>>>>>> 0 joshua@buttercup unnaturalcode 17617$ gdb --args >>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar >>>>>>> >>>>>>> Is the version of java used here the same as during jcc build time ? >>>>>>> >>>>>>> Andi.. >>>>>>> >>>>>>>> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar >>>>>>>> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git >>>>>>>> Copyright (C) 2016 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later >>>>>>>> <http://gnu.org/licenses/gpl. >>>>>>> html >>>>>>>>> >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show >>>>>>> copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "x86_64-linux-gnu". >>>>>>>> Type "show configuration" for configuration details. >>>>>>>> For bug reporting instructions, please see: >>>>>>>> <http://www.gnu.org/software/gdb/bugs/>. >>>>>>>> Find the GDB manual and other documentation resources online at: >>>>>>>> <http://www.gnu.org/software/gdb/documentation/>. >>>>>>>> For help, type "help". >>>>>>>> Type "apropos word" to search for commands related to "word"... >>>>>>>> Reading symbols from /home/joshua/unnaturalcode/ >>>>>>> venv3/bin/python...Reading >>>>>>>> symbols from >>>>>>>> /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a2 >>>>>>> 4b81b90e.debug...done. >>>>>>>> done. >>>>>>>> (gdb) r >>>>>>>> Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc >>>>>>> --jar >>>>>>>> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar >>>>>>>> [Thread debugging using libthread_db enabled] >>>>>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/ >>>>>>> libthread_db.so.1". >>>>>>>> Installing openjdk unwinder >>>>>>>> Traceback (most recent call last): >>>>>>>> File >>>>>>>> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/ >>>>>>> jre/lib/amd64/server/ >>>>>>>> libjvm.so-gdb.py", line 52, in <module> >>>>>>>> class Types(object): >>>>>>>> File >>>>>>>> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/ >>>>>>> jre/lib/amd64/server/ >>>>>>>> libjvm.so-gdb.py", line 66, in Types >>>>>>>> nmethodp_t = gdb.lookup_type('nmethod').pointer() >>>>>>>> gdb.error: No type named nmethod. >>>>>>>> >>>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>>> 0x00007fffe47f22b4 in ?? () >>>>>>>> (gdb) bt >>>>>>>> #0 0x00007fffe47f22b4 in ?? () >>>>>>>> #1 0x0000000000000246 in ?? () >>>>>>>> #2 0x00007fffe47f2160 in ?? () >>>>>>>> #3 0x00007fffffffc8c0 in ?? () >>>>>>>> #4 0x00007fffffffc860 in ?? () >>>>>>>> #5 0x00007ffff600d075 in VM_Version::get_processor_features() () >>>>>>>> from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/ >>>>>>> server/libjvm.so >>>>>>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Joshua Charles Campbell >>>>>>>> Ph.D. Student and Research Assistant >>>>>>>> Department of Computing Science >>>>>>>> University of Alberta >>>>>>>> josh...@ualberta.ca >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Joshua Charles Campbell >>>>>> Ph.D. Student and Research Assistant >>>>>> Department of Computing Science >>>>>> University of Alberta >>>>>> josh...@ualberta.ca >>>>> >>>> >>>> >>>> >>>> -- >>>> Joshua Charles Campbell >>>> Ph.D. Student and Research Assistant >>>> Department of Computing Science >>>> University of Alberta >>>> josh...@ualberta.ca >>> >>> >>> >>> -- >>> Joshua Charles Campbell >>> Ph.D. Student and Research Assistant >>> Department of Computing Science >>> University of Alberta >>> josh...@ualberta.ca >> > > > > -- > Joshua Charles Campbell > Ph.D. Student and Research Assistant > Department of Computing Science > University of Alberta > josh...@ualberta.ca -- Joshua Charles Campbell Ph.D. Student and Research Assistant Department of Computing Science University of Alberta josh...@ualberta.ca
