You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pylucene-dev@lucene.apache.org by Joshua Campbell <jo...@ualberta.ca> on 2017/07/05 16:25:20 UTC
JCC Segfault on Debian 9 (stretch)
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
Successfully installed jcc-3.0
0 joshua@buttercup unnaturalcode 17617$ gdb --args
/home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
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/fc2e1a3c58b6d241b3f9af7b2fb3a24b81b90e.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
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
> 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 <jo...@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 <jo...@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
>> > joshua2@ualberta.ca
>>
>>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
>
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
Hello friends. I tracked down the problem and attached my results to
the relevant bug report. The issue is caused by using kernels after
the patches for CVE-2017-1000364. It can be worked around in a variety
of different ways until the problem is fixed in the kernel or JVM. You
can disable CVE-2017-1000364 protection with a kernel argument I think
that might work. JCC can use more stack before calling JNI_initVM,
that should also work.
HERE IS THE EXPLANATION OF WHAT IS HAPPENING:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865303&archived=False&mbox=no#235
On Thu, Jul 6, 2017 at 3:50 PM, Joshua Campbell <jo...@ualberta.ca> wrote:
> 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 <jo...@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 <jo...@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 <jo...@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 <jo...@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
>>> >>>> <jo...@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 <jo...@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 <jo...@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
>>> >>>>>>>>> joshua2@ualberta.ca
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> Joshua Charles Campbell
>>> >>>>>>> Ph.D. Student and Research Assistant
>>> >>>>>>> Department of Computing Science
>>> >>>>>>> University of Alberta
>>> >>>>>>> joshua2@ualberta.ca
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Joshua Charles Campbell
>>> >>>>> Ph.D. Student and Research Assistant
>>> >>>>> Department of Computing Science
>>> >>>>> University of Alberta
>>> >>>>> joshua2@ualberta.ca
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Joshua Charles Campbell
>>> >>>> Ph.D. Student and Research Assistant
>>> >>>> Department of Computing Science
>>> >>>> University of Alberta
>>> >>>> joshua2@ualberta.ca
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Joshua Charles Campbell
>>> >> Ph.D. Student and Research Assistant
>>> >> Department of Computing Science
>>> >> University of Alberta
>>> >> joshua2@ualberta.ca
>>> >
>>> >
>>> >
>>> > --
>>> > Joshua Charles Campbell
>>> > Ph.D. Student and Research Assistant
>>> > Department of Computing Science
>>> > University of Alberta
>>> > joshua2@ualberta.ca
>>>
>>
>>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> joshua2@ualberta.ca
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Dirk Rothe <d....@semantics.de>.
I was bitten by this during jcc.initVM():
https://www.cloudlinux.com/cloudlinux-os-blog/entry/jvm-crashes-occurring-after-upgrading-to-a-kernel-with-the-fix-for-stack-clash
Maybe related...
--dirk
Am 06.07.2017, 23:50 Uhr, schrieb Joshua Campbell <jo...@ualberta.ca>:
> 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 <jo...@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 <jo...@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
>>> <jo...@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 <jo...@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
>>> >>>> <jo...@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 <jo...@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
>>> <jo...@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
>>> >>>>>>>>> joshua2@ualberta.ca
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> Joshua Charles Campbell
>>> >>>>>>> Ph.D. Student and Research Assistant
>>> >>>>>>> Department of Computing Science
>>> >>>>>>> University of Alberta
>>> >>>>>>> joshua2@ualberta.ca
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Joshua Charles Campbell
>>> >>>>> Ph.D. Student and Research Assistant
>>> >>>>> Department of Computing Science
>>> >>>>> University of Alberta
>>> >>>>> joshua2@ualberta.ca
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Joshua Charles Campbell
>>> >>>> Ph.D. Student and Research Assistant
>>> >>>> Department of Computing Science
>>> >>>> University of Alberta
>>> >>>> joshua2@ualberta.ca
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Joshua Charles Campbell
>>> >> Ph.D. Student and Research Assistant
>>> >> Department of Computing Science
>>> >> University of Alberta
>>> >> joshua2@ualberta.ca
>>> >
>>> >
>>> >
>>> > --
>>> > Joshua Charles Campbell
>>> > Ph.D. Student and Research Assistant
>>> > Department of Computing Science
>>> > University of Alberta
>>> > joshua2@ualberta.ca
>>>
>>
>>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> joshua2@ualberta.ca
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
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 <jo...@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 <jo...@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 <jo...@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 <jo...@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
>> >>>> <jo...@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 <jo...@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 <jo...@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
>> >>>>>>>>> joshua2@ualberta.ca
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Joshua Charles Campbell
>> >>>>>>> Ph.D. Student and Research Assistant
>> >>>>>>> Department of Computing Science
>> >>>>>>> University of Alberta
>> >>>>>>> joshua2@ualberta.ca
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Joshua Charles Campbell
>> >>>>> Ph.D. Student and Research Assistant
>> >>>>> Department of Computing Science
>> >>>>> University of Alberta
>> >>>>> joshua2@ualberta.ca
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Joshua Charles Campbell
>> >>>> Ph.D. Student and Research Assistant
>> >>>> Department of Computing Science
>> >>>> University of Alberta
>> >>>> joshua2@ualberta.ca
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Joshua Charles Campbell
>> >> Ph.D. Student and Research Assistant
>> >> Department of Computing Science
>> >> University of Alberta
>> >> joshua2@ualberta.ca
>> >
>> >
>> >
>> > --
>> > Joshua Charles Campbell
>> > Ph.D. Student and Research Assistant
>> > Department of Computing Science
>> > University of Alberta
>> > joshua2@ualberta.ca
>>
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
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 <jo...@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 <jo...@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 <jo...@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 <jo...@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 <jo...@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 <jo...@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
> >>>>>>>>> joshua2@ualberta.ca
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Joshua Charles Campbell
> >>>>>>> Ph.D. Student and Research Assistant
> >>>>>>> Department of Computing Science
> >>>>>>> University of Alberta
> >>>>>>> joshua2@ualberta.ca
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Joshua Charles Campbell
> >>>>> Ph.D. Student and Research Assistant
> >>>>> Department of Computing Science
> >>>>> University of Alberta
> >>>>> joshua2@ualberta.ca
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Joshua Charles Campbell
> >>>> Ph.D. Student and Research Assistant
> >>>> Department of Computing Science
> >>>> University of Alberta
> >>>> joshua2@ualberta.ca
> >>>
> >>
> >>
> >>
> >> --
> >> Joshua Charles Campbell
> >> Ph.D. Student and Research Assistant
> >> Department of Computing Science
> >> University of Alberta
> >> joshua2@ualberta.ca
> >
> >
> >
> > --
> > Joshua Charles Campbell
> > Ph.D. Student and Research Assistant
> > Department of Computing Science
> > University of Alberta
> > joshua2@ualberta.ca
>
>
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Andi Vajda <va...@apache.org>.
> On Jul 6, 2017, at 00:03, Joshua Campbell <jo...@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 <jo...@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 <jo...@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 <jo...@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 <jo...@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 <jo...@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
>>>>>>>>> joshua2@ualberta.ca
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joshua Charles Campbell
>>>>>>> Ph.D. Student and Research Assistant
>>>>>>> Department of Computing Science
>>>>>>> University of Alberta
>>>>>>> joshua2@ualberta.ca
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joshua Charles Campbell
>>>>> Ph.D. Student and Research Assistant
>>>>> Department of Computing Science
>>>>> University of Alberta
>>>>> joshua2@ualberta.ca
>>>>
>>>>
>>>>
>>>> --
>>>> Joshua Charles Campbell
>>>> Ph.D. Student and Research Assistant
>>>> Department of Computing Science
>>>> University of Alberta
>>>> joshua2@ualberta.ca
>>>
>>
>>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> joshua2@ualberta.ca
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
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.
On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell <jo...@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 <jo...@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 <jo...@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 <jo...@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 <jo...@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
>>>>>>>> joshua2@ualberta.ca
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joshua Charles Campbell
>>>>>> Ph.D. Student and Research Assistant
>>>>>> Department of Computing Science
>>>>>> University of Alberta
>>>>>> joshua2@ualberta.ca
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Joshua Charles Campbell
>>>> Ph.D. Student and Research Assistant
>>>> Department of Computing Science
>>>> University of Alberta
>>>> joshua2@ualberta.ca
>>>
>>>
>>>
>>> --
>>> Joshua Charles Campbell
>>> Ph.D. Student and Research Assistant
>>> Department of Computing Science
>>> University of Alberta
>>> joshua2@ualberta.ca
>>
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
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 <jo...@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 <jo...@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 <jo...@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 <jo...@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
>>>>>>> joshua2@ualberta.ca
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joshua Charles Campbell
>>>>> Ph.D. Student and Research Assistant
>>>>> Department of Computing Science
>>>>> University of Alberta
>>>>> joshua2@ualberta.ca
>>>>
>>>
>>>
>>>
>>> --
>>> Joshua Charles Campbell
>>> Ph.D. Student and Research Assistant
>>> Department of Computing Science
>>> University of Alberta
>>> joshua2@ualberta.ca
>>
>>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> joshua2@ualberta.ca
>
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Andi Vajda <va...@apache.org>.
> On Jul 5, 2017, at 22:16, Joshua Campbell <jo...@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 <jo...@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 <jo...@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 <jo...@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
>>>>>> joshua2@ualberta.ca
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Joshua Charles Campbell
>>>> Ph.D. Student and Research Assistant
>>>> Department of Computing Science
>>>> University of Alberta
>>>> joshua2@ualberta.ca
>>>
>>
>>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> joshua2@ualberta.ca
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
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
On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell <jo...@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 <jo...@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 <jo...@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
>> >>> joshua2@ualberta.ca
>> >>
>> >>
>> >
>> >
>> > --
>> > Joshua Charles Campbell
>> > Ph.D. Student and Research Assistant
>> > Department of Computing Science
>> > University of Alberta
>> > joshua2@ualberta.ca
>>
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
> 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 <jo...@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 <jo...@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
> >>> joshua2@ualberta.ca
> >>
> >>
> >
> >
> > --
> > Joshua Charles Campbell
> > Ph.D. Student and Research Assistant
> > Department of Computing Science
> > University of Alberta
> > joshua2@ualberta.ca
>
>
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Andi Vajda <va...@apache.org>.
On Jul 5, 2017, at 18:56, Joshua Campbell <jo...@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 <jo...@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
>>> joshua2@ualberta.ca
>>
>>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Joshua Campbell <jo...@ualberta.ca>.
> 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 <jo...@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
> > joshua2@ualberta.ca
>
>
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Re: JCC Segfault on Debian 9 (stretch)
Posted by Andi Vajda <va...@apache.org>.
> On Jul 5, 2017, at 18:25, Joshua Campbell <jo...@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/fc2e1a3c58b6d241b3f9af7b2fb3a24b81b90e.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
> joshua2@ualberta.ca