> What version if java is this jcc built with ? Oh it's openjdk-8-dbg_8u131-b11-2
But I got a same result (the stacktrace was slightly different but still undecoded) with Oracle's JDK. On Wed, Jul 5, 2017 at 10:56 AM, 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. > > > 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. > > 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/ven >> v3/bin/python...Reading >> > symbols from >> > /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a24b >> 81b90e.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/libthre >> ad_db.so.1". >> > Installing openjdk unwinder >> > Traceback (most recent call last): >> > File >> > "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/j >> re/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/j >> re/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
