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
