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
