Hello friends. I tracked down the problem and attached my results to the relevant bug report. The issue is caused by using kernels after the patches for CVE-2017-1000364. It can be worked around in a variety of different ways until the problem is fixed in the kernel or JVM. You can disable CVE-2017-1000364 protection with a kernel argument I think that might work. JCC can use more stack before calling JNI_initVM, that should also work.
HERE IS THE EXPLANATION OF WHAT IS HAPPENING: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303&archived=False&mbox=no#235 On Thu, Jul 6, 2017 at 3:50 PM, Joshua Campbell <josh...@ualberta.ca> wrote: > Okay so. I built GDB 8 from source (it's new) and that doesn't have bug. > > In summary: > > Ok TO BE CLEAR, I am closer to the TRUTH than ever. Not only am I not > stopping, I am working harder. Updates when available. Stay tuned! > > It turns out the JVM is crashing on the line commented with "// > Generate SEGV" so something about Python/JNI/JCC is intefering with > the JVM's signal handler, as this SEGV is intentional! > > > > On Thu, Jul 6, 2017 at 12:44 AM, Joshua Campbell <josh...@ualberta.ca> wrote: >> How would they break oracle's though. It's a binary. >> >> On Wed, Jul 5, 2017 at 10:40 PM, Andi Vajda <va...@apache.org> wrote: >>> >>> >>> > On Jul 6, 2017, at 00:03, Joshua Campbell <josh...@ualberta.ca> wrote: >>> > >>> > 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. >>> >>> Hmmm, maybe JNI is broken on Debian 9 ? >>> >>> Andi.. >>> >>> > >>> >> 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 >>> >> >> >> >> -- >> 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
