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
