[GRIP] Error when starting grip on RPI

We followed this tutorial for setting up GRIP on RPI, the dependencies and deploy worked fine, etc., but then when we tried to run it (over ssh) we got an error that produced this report file:


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0xabb5de18, pid=13064, tid=3057296480
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132)
# Java VM: Java HotSpot(TM) Client VM (25.0-b70 mixed mode linux-arm )
# Problematic frame:
# C  [libstdc++.so.6+0x6ce18]  wmemset+0x6ce18
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0xb62059d0):  JavaThread "main" [_thread_in_native, id=13065, stack(0xb635b000,0xb63ab000)]

siginfo:si_signo=SIGILL: si_errno=0, si_code=1 (ILL_ILLOPC), si_addr=0xabb5de18

Registers:
  r0  = 0xabbf79d4
  r1  = 0xbeccc774
  r2  = 0x00000000
  r3  = 0xabbfc000
  r4  = 0x00000001
  r5  = 0xabbf79a4
  r6  = 0x00000004
  r7  = 0xbeccc774
  r8  = 0xb6261f80
  r9  = 0x0000000b
  r10 = 0x00000000
  fp  = 0xb63a795c
  r12 = 0xabb5de0d
  sp  = 0xb63a78a8
  lr  = 0xb6f9a058
  pc  = 0xabb5de18
  cpsr = 0x00000030

Top of Stack: (sp=0xb63a78a8)
0xb63a78a8:   001069a4 b6f9a058 b6261f80 00000004
0xb63a78b8:   00000002 abfc1a30 00000004 beccc774
0xb63a78c8:   b6261f80 b6f9a134 abfc1a30 b6fba050
0xb63a78d8:   00000006 00000018 b6fba568 00000194
0xb63a78e8:   abfc1b8c b6f9e6b4 00010001 abfae168
0xb63a78f8:   abfc1a30 abfc1cd0 80000000 00000000
0xb63a7908:   0000001c b6201700 abfc1a30 b63a78f0
0xb63a7918:   b63a7900 b63a7900 00000010 00000008 

Instructions: (pc=0xabb5de18)
0xabb5ddf8:   0009fa6a 0009e228 0000169c 0009f8ea
0xabb5de08:   0009fa4a b5084807 68024478 447b4b06
0xabb5de18:   e8bdb912 e7bb4008 589b4a04 d0f82b00
0xabb5de28:   e7f64798 00099bc0 0009e1e6 00000eb8 

Register to memory mapping:

  r0  = 0xabbf79d4
0xabbf79d4: <offset 0x1069d4> in /home/pi/vision/grip/libstdc++.so.6 at 0xabaf1000

  r1  = 0xbeccc774
0xbeccc774 is an unknown value

  r2  = 0x00000000
0x00000000 is an unknown value

  r3  = 0xabbfc000
0xabbfc000: <offset 0x10b000> in /home/pi/vision/grip/libstdc++.so.6 at 0xabaf1000

  r4  = 0x00000001
0x00000001 is an unknown value

  r5  = 0xabbf79a4
0xabbf79a4: <offset 0x1069a4> in /home/pi/vision/grip/libstdc++.so.6 at 0xabaf1000

  r6  = 0x00000004
0x00000004 is an unknown value

  r7  = 0xbeccc774
0xbeccc774 is an unknown value

  r8  = 0xb6261f80
0xb6261f80 is an unknown value

  r9  = 0x0000000b
0x0000000b is an unknown value

  r10 = 0x00000000
0x00000000 is an unknown value

  fp  = 0xb63a795c
0xb63a795c is pointing into the stack for thread: 0xb62059d0

  r12 = 0xabb5de0d
0xabb5de0d: <offset 0x6ce0d> in /home/pi/vision/grip/libstdc++.so.6 at 0xabaf1000

  sp  = 0xb63a78a8
0xb63a78a8 is pointing into the stack for thread: 0xb62059d0

  lr  = 0xb6f9a058
0xb6f9a058: <offset 0x10058> in /lib/ld-linux-armhf.so.3 at 0xb6f8a000

  pc  = 0xabb5de18
0xabb5de18: <offset 0x6ce18> in /home/pi/vision/grip/libstdc++.so.6 at 0xabaf1000



Stack: [0xb635b000,0xb63ab000],  sp=0xb63a78a8,  free space=306k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libstdc++.so.6+0x6ce18]  wmemset+0x6ce18

Does anyone know how to fix this?

What OS are you running on your raspberry pi? Its working for me running Raspbian Jessie. Also these instructions only work for Pi 2. Are you running on a Pi 1?

It is a Pi 1. I didn’t realize. ARM v6 versus v7 of course. facepalm Is there an existing version for v6 or must I find a way to compile it for myself.

Its going to be harder to get a Pi 1 build. You will have to compile both ntcore and Java CV properly. Then get those integrated into GRIP and recompile GRIP.

Yeah I think we’ll just find a Pi 2