> On Jul 6, 2017, at 00:03, Joshua Campbell <josh...@ualberta.ca>
wrote:
>
> I confirmed that it crashes on multiple Debian 9 machines but it
> doesn't crash on Ubuntu 16.04. This behavior is consistent regardless
> of the JDK used (I tried openjdk 8, oracle 8 and openjdk 9). I am at
a
> loss for how to track it down further due to the (apparent) GDB bug.
Hmmm, maybe JNI is broken on Debian 9 ?
Andi..
>
>> On Wed, Jul 5, 2017 at 2:39 PM, Joshua Campbell
<josh...@ualberta.ca>
>> wrote:
>> No, it segfaults.
>>
>>> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda <va...@apache.org>
wrote:
>>>
>>>> On Jul 5, 2017, at 22:16, Joshua Campbell <josh...@ualberta.ca>
>>>> wrote:
>>>>
>>>> It's occuring after JCC calls JNI_CreateJavaVM
>>>>
>>>> cpp.py(529): env = initVM(os.pathsep.join(classpath) or None,
>>>> **initvm_args)
>>>> ^^^^^ last python trace before death
>>>>
>>>> Breakpoint 5, initVM (self=0x7ffff7e05048, args=0x7ffff66deac8,
>>>> kwds=0x7ffff7e00ec8) at jcc3/sources/jcc.cpp:527
>>>> 527 if (JNI_CreateJavaVM(&vm, (void **) &vm_env,
>>>> &vm_args) < 0)
>>>> ^^^^ last line of jcc.cpp before death
>>>>
>>>> (gdb) step
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x00007fffe43942b4 in ?? ()
>>>> (gdb)
>>>>
>>>>
>>>> AFTER fixing debians debugging symbols with ln -s
>>>> /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
>>>> /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64
>>>>
>>>> Breakpoint 1, JNI_CreateJavaVM (vm=0x7fffffffc420,
>>>> penv=0x7fffffffc418,
>>>> args=0x7fffffffc450) at
>>>> ./src/hotspot/src/share/vm/prims/jni.cpp:5161
>>>> 5161 ./src/hotspot/src/share/vm/prims/jni.cpp: No such file or
>>>> directory.
>>>> (gdb) s
>>>> JNI_CreateJavaVM (vm=0x7fffffffc420, penv=0x7fffffffc418,
>>>> args=0x7fffffffc450)
>>>> at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
>>>> 5163 in ./src/hotspot/src/share/vm/prims/jni.cpp
>>>> (gdb)
>>>> /build/gdb-A87voC/gdb-7.12/gdb/inline-frame.c:167: internal-error:
>>>> void inline_frame_this_id(frame_info*, void**, frame_id*):
Assertion
>>>> `frame_id_p (*this_id)' failed.
>>>> A problem internal to GDB has been detected,
>>>> further debugging may prove unreliable.
>>>> Quit this debugging session? (y or n) n
>>>>
>>>> This is a bug, please report it. For instructions, see:
>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>>
>>>> What in the name of heck
>>>
>>> Does it run without gdb ?
>>>
>>> Andi..
>>>
>>>>
>>>> On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell
>>>> <josh...@ualberta.ca> wrote:
>>>>>> But you should get a better stacktrace ?
>>>>>
>>>>> I got the exact same stacktrace.
>>>>>
>>>>> $ ldd
>>>>>
>>>>>
venv3/lib/python3.5/site-packages/JCC-3.0-py3.5-linux-x86_64.egg/libjcc3.so
>>>>> linux-vdso.so.1 (0x00007ffcf4eb8000)
>>>>> libjava.so =>
>>>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
>>>>> (0x00007f412227f000)
>>>>> libjvm.so =>
>>>>>
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>>>>> (0x00007f412133d000)
>>>>> libpython3.5m.so.1.0 =>
>>>>> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
(0x00007f4120c3a000)
>>>>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>>> (0x00007f41208b8000)
>>>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>>>>> (0x00007f41205b4000)
>>>>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>>>>> (0x00007f412039b000)
>>>>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>>>>> (0x00007f412017e000)
>>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>>>>> (0x00007f411fddf000)
>>>>> libverify.so =>
>>>>> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
>>>>> (0x00007f411fbce000)
>>>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
>>>>> (0x00007f411f9ca000)
>>>>> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
>>>>> (0x00007f411f7a0000)
>>>>> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
>>>>> (0x00007f411f584000)
>>>>> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
>>>>> (0x00007f411f381000)
>>>>> /lib64/ld-linux-x86-64.so.2 (0x000055857b9dd000)
>>>>>
>>>>> I did verify it's compiling with -g
>>>>>
>>>>> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
>>>>> -Wstrict-prototypes -g
>>>>> -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=.
>>>>> -fstack-protector-strong -Wformat -Werror=format-security
>>>>> -Wdate-time
>>>>> -D_FORTIFY_SOURCE=2 -fPIC -g -D_java_generics -DJCC_VER="3.0"
>>>>> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include
>>>>> -I/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux -I_jcc3
>>>>> -Ijcc3/sources
>>>>> -I/usr/include/python3.5m
>>>>> -I/home/joshua/unnaturalcode/venv3/include/python3.5m -c
>>>>> _jcc3/java/lang/String.cpp -o
>>>>> build/temp.linux-x86_64-3.5/_jcc3/java/lang/String.o -DPYTHON
>>>>> -fno-strict-aliasing -Wno-write-strings -O0 -g -DDEBUG
>>>>>
>>>>> But it's still producing
>>>>>
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x00007fffe47eb2b4 in ?? ()
>>>>> (gdb) bt
>>>>> #0 0x00007fffe47eb2b4 in ?? ()
>>>>> #1 0x0000000000000246 in ?? ()
>>>>> #2 0x00007fffe47eb160 in ?? ()
>>>>> #3 0x00007fffffffc840 in ?? ()
>>>>> #4 0x00007fffffffc7e0 in ?? ()
>>>>> #5 0x00007ffff6006075 in VM_Version::get_processor_features() ()
>>>>> from
>>>>>
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>>>>> Backtrace stopped: previous frame inner to this frame (corrupt
>>>>> stack?)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, Jul 5, 2017 at 11:38 AM, Andi Vajda <va...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Jul 5, 2017, at 18:56, Joshua Campbell <josh...@ualberta.ca>
>>>>>> wrote:
>>>>>>
>>>>>>>> What version if java is this jcc built with ?
>>>>>>>> To build jcc for debugging with gcc add --debug to the build
>>>>>>>> command.
>>>>>>>> You
>>>>>>> should then have symbols visible to gdb.
>>>>>>>
>>>>>>> You mean with setup.py build --debug ? I tried that on trunk
and
>>>>>>> got the
>>>>>>> same result.
>>>>>>
>>>>>> But you should get a better stacktrace ?
>>>>>>
>>>>>>>> Is the version of java used here the same as during jcc build
>>>>>>>> time ?
>>>>>>>
>>>>>>> Yes I made sure of that and uninstalled all but openjdk and
>>>>>>> rebuilt.
>>>>>>
>>>>>> Did you verify this via running 'ldd' on the shared libraries
>>>>>> involved ?
>>>>>>
>>>>>> That being said, it could be something different of course !
>>>>>>
>>>>>> Andi..
>>>>>>
>>>>>>>
>>>>>>>> On Wed, Jul 5, 2017 at 10:46 AM, Andi Vajda <va...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jul 5, 2017, at 18:25, Joshua Campbell
<josh...@ualberta.ca>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> This segfault appears to occur within the JVM code on both
>>>>>>>> oracle-java8-jdk
>>>>>>>>> and
>>>>>>>>> java-1.8.0-openjdk-amd64. I installed the JVM debugging
symbols
>>>>>>>>> but it
>>>>>>>>> didn't seem to help.
>>>>>>>>>
>>>>>>>>> Occurs under python 2 and 3. I don't know how to debug this
any
>>>>>>>>> further.
>>>>>>>>>
>>>>>>>>> 0 joshua@buttercup unnaturalcode 17609$ python3 -m
virtualenv -p
>>>>>>>>> python3
>>>>>>>>> venv3 Already using interpreter /usr/bin/python3
>>>>>>>>> Using base prefix '/usr'
>>>>>>>>> New python executable in
>>>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python3
>>>>>>>>> Also creating executable in
>>>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python
>>>>>>>>> Installing setuptools, pkg_resources, pip, wheel...done.
>>>>>>>>> 0 joshua@buttercup unnaturalcode 17610$ source
>>>>>>>>> venv3/bin/activate
>>>>>>>>> 0 joshua@buttercup unnaturalcode 17611$ which python
>>>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python
>>>>>>>>> 0 joshua@buttercup unnaturalcode 17616$ pip install jcc
>>>>>>>>> --no-cache-dir
>>>>>>>>> Collecting jcc
>>>>>>>>> Downloading JCC-3.0.tar.gz (176kB)
>>>>>>>>> 100% |████████████████████████████████| 184kB 3.4MB/s
>>>>>>>>> Installing collected packages: jcc
>>>>>>>>> Running setup.py install for jcc ... done
>>>>>>>>
>>>>>>>> What version if java is this jcc built with ?
>>>>>>>> To build jcc for debugging with gcc add --debug to the build
>>>>>>>> command.
>>>>>>>> You
>>>>>>>> should then have symbols visible to gdb.
>>>>>>>>
>>>>>>>>> Successfully installed jcc-3.0
>>>>>>>>> 0 joshua@buttercup unnaturalcode 17617$ gdb --args
>>>>>>>>> /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
>>>>>>>>
>>>>>>>> Is the version of java used here the same as during jcc build
>>>>>>>> time ?
>>>>>>>>
>>>>>>>> Andi..
>>>>>>>>
>>>>>>>>> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
>>>>>>>>> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
>>>>>>>>> Copyright (C) 2016 Free Software Foundation, Inc.
>>>>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>>>>> <http://gnu.org/licenses/gpl.
>>>>>>>> html
>>>>>>>>>>
>>>>>>>>> This is free software: you are free to change and
redistribute
>>>>>>>>> it.
>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type
>>>>>>>>> "show
>>>>>>>> copying"
>>>>>>>>> and "show warranty" for details.
>>>>>>>>> This GDB was configured as "x86_64-linux-gnu".
>>>>>>>>> Type "show configuration" for configuration details.
>>>>>>>>> For bug reporting instructions, please see:
>>>>>>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>>>>>>> Find the GDB manual and other documentation resources online
at:
>>>>>>>>> <http://www.gnu.org/software/gdb/documentation/>.
>>>>>>>>> For help, type "help".
>>>>>>>>> Type "apropos word" to search for commands related to
"word"...
>>>>>>>>> Reading symbols from /home/joshua/unnaturalcode/
>>>>>>>> venv3/bin/python...Reading
>>>>>>>>> symbols from
>>>>>>>>> /usr/lib/debug/.build-id/db/fc2e1a3c58b6d241b3f9af7b2fb3a2
>>>>>>>> 4b81b90e.debug...done.
>>>>>>>>> done.
>>>>>>>>> (gdb) r
>>>>>>>>> Starting program:
/home/joshua/unnaturalcode/venv3/bin/python -m
>>>>>>>>> jcc
>>>>>>>> --jar
>>>>>>>>> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
>>>>>>>>> [Thread debugging using libthread_db enabled]
>>>>>>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/
>>>>>>>> libthread_db.so.1".
>>>>>>>>> Installing openjdk unwinder
>>>>>>>>> Traceback (most recent call last):
>>>>>>>>> File
>>>>>>>>> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/
>>>>>>>> jre/lib/amd64/server/
>>>>>>>>> libjvm.so-gdb.py", line 52, in <module>
>>>>>>>>> class Types(object):
>>>>>>>>> File
>>>>>>>>> "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/
>>>>>>>> jre/lib/amd64/server/
>>>>>>>>> libjvm.so-gdb.py", line 66, in Types
>>>>>>>>> nmethodp_t = gdb.lookup_type('nmethod').pointer()
>>>>>>>>> gdb.error: No type named nmethod.
>>>>>>>>>
>>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>>> 0x00007fffe47f22b4 in ?? ()
>>>>>>>>> (gdb) bt
>>>>>>>>> #0 0x00007fffe47f22b4 in ?? ()
>>>>>>>>> #1 0x0000000000000246 in ?? ()
>>>>>>>>> #2 0x00007fffe47f2160 in ?? ()
>>>>>>>>> #3 0x00007fffffffc8c0 in ?? ()
>>>>>>>>> #4 0x00007fffffffc860 in ?? ()
>>>>>>>>> #5 0x00007ffff600d075 in
VM_Version::get_processor_features()
>>>>>>>>> ()
>>>>>>>>> from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/
>>>>>>>> server/libjvm.so
>>>>>>>>> Backtrace stopped: previous frame inner to this frame
(corrupt
>>>>>>>>> stack?)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joshua Charles Campbell
>>>>>>>>> Ph.D. Student and Research Assistant
>>>>>>>>> Department of Computing Science
>>>>>>>>> University of Alberta
>>>>>>>>> josh...@ualberta.ca
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joshua Charles Campbell
>>>>>>> Ph.D. Student and Research Assistant
>>>>>>> Department of Computing Science
>>>>>>> University of Alberta
>>>>>>> josh...@ualberta.ca
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joshua Charles Campbell
>>>>> Ph.D. Student and Research Assistant
>>>>> Department of Computing Science
>>>>> University of Alberta
>>>>> josh...@ualberta.ca
>>>>
>>>>
>>>>
>>>> --
>>>> Joshua Charles Campbell
>>>> Ph.D. Student and Research Assistant
>>>> Department of Computing Science
>>>> University of Alberta
>>>> josh...@ualberta.ca
>>>
>>
>>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> josh...@ualberta.ca
>
>
>
> --
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> josh...@ualberta.ca
