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

Reply via email to