> 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
