Re: JCC Segfault on Debian 9 (stretch)

[Joshua Campbell]

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  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  wrote:
>> How would they break oracle's though. It's a binary.
>>
>> On Wed, Jul 5, 2017 at 10:40 PM, Andi Vajda  wrote:
>>>
>>>
>>> > On Jul 6, 2017, at 00:03, Joshua Campbell  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 
>>> >> wrote:
>>> >> No, it segfaults.
>>> >>
>>> >>> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda  wrote:
>>> >>>
>>>  On Jul 5, 2017, at 22:16, Joshua Campbell 
>>>  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=0x77e05048, args=0x766deac8,
>>>    kwds=0x77e00ec8) 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.
>>>  0x7fffe43942b4 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=0x7fffc420,
>>>  penv=0x7fffc418,
>>>    args=0x7fffc450) 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=0x7fffc420, penv=0x7fffc418,
>>>  args=0x7fffc450)
>>>    at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
>>>  5163in ./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:
>>>  .
>>> 
>>>  What in the name of heck
>>> >>>
>>> >>> Does it run without gdb ?
>>> >>>
>>> >>> Andi..
>>> >>>
>>> 
>>>  On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell
>>>   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 (0x7ffcf4eb8000)
>>> >   libjava.so =>
>>> > /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
>>> > (0x7f412227f000)
>>> >   libjvm.so =>
>>> > /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
>>> > (0x7f412133d000)
>>> >   libpython3.5m.so.1.0 =>
>>> > /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0 (0x7f4120c3a000)
>>> >   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>> > (0x7f41208b8000)
>>> >   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>>> > (0x7f41205b4000)
>>> >   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> > (0x7f412039b000)
>>> >   libpthread.so.0 => /lib/x86_64-linux-gnu/l

Re: JCC Segfault on Debian 9 (stretch)

[Dirk Rothe]

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 :


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   
wrote:

How would they break oracle's though. It's a binary.

On Wed, Jul 5, 2017 at 10:40 PM, Andi Vajda  wrote:



> On Jul 6, 2017, at 00:03, Joshua Campbell   
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  


>> wrote:
>> No, it segfaults.
>>
>>> On Wed, Jul 5, 2017 at 2:26 PM, Andi Vajda   
wrote:

>>>
 On Jul 5, 2017, at 22:16, Joshua Campbell 
 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=0x77e05048, args=0x766deac8,
   kwds=0x77e00ec8) 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.
 0x7fffe43942b4 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=0x7fffc420,
 penv=0x7fffc418,
   args=0x7fffc450) 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=0x7fffc420, penv=0x7fffc418,
 args=0x7fffc450)
   at ./src/hotspot/src/share/vm/prims/jni.cpp:5163
 5163in ./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:
 .

 What in the name of heck
>>>
>>> Does it run without gdb ?
>>>
>>> Andi..
>>>

 On Wed, Jul 5, 2017 at 11:48 AM, Joshua Campbell
  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 (0x7ffcf4eb8000)
>   libjava.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libjava.so
> (0x7f412227f000)
>   libjvm.so =>
>  
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so

> (0x7f412133d000)
>   libpython3.5m.so.1.0 =>
> /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0  
(0x7f4120c3a000)

>   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f41208b8000)
>   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> (0x7f41205b4000)
>   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f412039b000)
>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f412017e000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x7f411fddf000)
>   libverify.so =>
> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/libverify.so
> (0x7f411fbce000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x7f411f9ca000)
>   libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x7f411f7a)
>   libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
> (0x7f411f584000)
>   libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
> (0x7f411f381000)
>   /lib64/ld-linux-x86-64.so.2 (0x55857b9dd000)
>
> I did verify it's compiling with -g
>
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwr