I'm trying to launch a java application on an ARM platform running Ubuntu 10.04. When using the plain java command it runs fine. When trying to use cacao vm java -cacao then I get the following error:
LOG: [0x2aac4540] trap_handle: Unknown trap instruction at 0x2efa793c
LOG: [0x2aac4540] PC=0x2efa793c
LOG: [0x2aac4540] Aborting...
LOG: [0x2aac4540] Backtrace (4 stack frames):
LOG: [0x2aac4540] /usr/lib/jvm/java-6-openjdk/jre/lib/arm/cacao/libjvm.so(+0x36244) [0x2ac58244]
LOG: [0x2aac4540] /usr/lib/jvm/java-6-openjdk/jre/lib/arm/cacao/libjvm.so(+0x363da) [0x2ac583da]
LOG: [0x2aac4540] /usr/lib/jvm/java-6-openjdk/jre/lib/arm/cacao/libjvm.so(+0x3e11e) [0x2ac6011e]
LOG: [0x2aac4540] /usr/lib/jvm/java-6-openjdk/jre/lib/arm/cacao/libjvm.so(+0x47248) [0x2ac69248]
The java version i use:
$ java -cacao -version
java version "1.6.0_18"
IcedTea Runtime Environment (1.8.13) (6b18-1.8.13-0ubuntu1~10.04.1)
CACAO (build 1.1.0pre2, compiled mode)
Is there something wrong with my application?
Is there a way to tell which instruction actually causes the error?
Do I miss something else what is needed to use caco vm?
According to CACAO developers this CACAO version as well as the IcedTea version are completely outdated. It seems that Ubuntu 10.04 OpenJDK on arm is not actively maintained.
To get CACAO VM working a compilation from source is needed. There is a little how-to in the CACAO wiki on how to build CACAO with IcedTea.
Related
System information
Linux Ubuntu 18.04
armv7 board
python3.6
question description
I trained a model on my linux server (ubuntu18.04，Intel(R) Xeon(R) W-2145 CPU) and exported it to tflite mode, and the model on the server (tflite-runtime=2.10.0) works fine.
Now I want to run the model on an armv7 development board of zynq7000. The operating system running on my board version is ubuntu18.04, and python3.6 and tflite-runtime=2.5.0 is installed (2.5.0 seems is the highest version I can get on armv7), but when I run interpreter = tflite.Interpreter(model_path=my_model), it throws Segmentation fault (core dumped) error.
After my test, if I downgrade the tflite-runtime on my linux server to version 2.5.0, the same error will be thrown. So I think the reason for the error may be that the version of tflite-runtime is too low.
But I can't get a higher version of tflite-runtime on armv7 board, does anyone know a solution please?
I work on a project on GNU Radio 3.8.3.1 and I use USRP N210 on this project. When I run the flow graph it gives the following error:
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
Also, when I tried to run the command uhd_find_devices on the terminal (Ubuntu 18.04) it gives this error:
[INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_4.2.0.git-209-gf23ab721
No UHD Devices Found
However, when I used ping "IP address of usrp", it pinged successfully. Any idea what is the problem?
I've installed (OSX Mojave 10.14.6.) Eclipse CDT and GNU MCU Eclipse plugin and finaly GNU Tools for ARM. My goal is to build and debug ARM code using GDB (arm-none-eabi-gdb).
I've created a Hello World project for Arm, which builds ok - but, debugging seems not to work with GDB (that comes with the Arm package). GDB gets stuck:
I have set the proper paths in Eclipse to arm-none-eabi-gdb.
I have signed the arm-none-eabi-gdb (with the same certificate that I used to sign GDB installed via brew into /usr/local/bin/gdb the day before - and it worked!).
I have also tried running Eclipse as root from command line.
Nothing helps.
The message is "Configuring GDB Aborting configuring GDB".
What to do?
Probably what is going on here is that you built to a given target (ARM based) and you're trying to run it (with gdb) on your mac (x86).
You'll need an emulator or QEMU to properly run on your mac or maybe a real board.
I am getting these two errors while doing make all in qualcomm cdb20
make: arm-none-eabi-gcc: Command not found
make: *** [qurt_init.o] Error 127*
The Error No:127, is returned if the tool chain path is not specified in environment variables.
The toolchain for Qualcomm cdb20 which supports both Windows and Linux platform can be downloaded from the
ARM website at: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
Supported version: 6.2
Once toolchain is downloaded, add the path of toolchain binaries to ‘PATH’ environment variable.
Linux:
export PATH=$PATH:/path/to/bin
Windows:
set %PATH%=%PATH%:\path\to\bin
kindly refer user guide provided by Qualcomm
I installed frama-c Magnesium version using instruction provided here. I didn't get any error during installation and executing command frama-c -versionin Cygwin printed Frama-c version as: Magnesium-20151002. But when I executed -wp plugin on a very small example, for the goals which used alt-ergo, I get following errors:
1 [main] frama-c 8168 child_info_fork::abort: unable to map C:\cygwin\usr\local\lib\frama-c\plugins\Users.cmxs, Win32 error 998
1 [main] frama-c 7956 child_info_fork::abort: unable to map C:\cygwin\usr\local\lib\frama-c\plugins\Value.cmxs, Win32 error 998
0 [main] frama-c 300 child_info_fork::abort: unable to map C:\cygwin\usr\local\lib\frama-c\plugins\Value.cmxs, Win32 error 998 [wp] [Alt-Ergo] Goal typed_changeCase_assert_rte_signed_overflow_2 : Failed
Error: Resource temporarily unavailable
Value plugin executes successfully. I searched the error and found this post. So I also executed rebaseall -v command, but that too didn't help. To confirm that my Cygwin is not corrupted I installed Frama-c Sodium version again and was able to execute WP plugin successfully.
Can anyone help me fix this issue, we want to be able to use Frama-c Magnesium version on Windows?
Edit: Machine details:
I tried it on my computer and also on a VM. On VM, I executed commands ./configure && make and make install to install frama-c Magnesium.
I have 32 bit Cygwin on both machine. Both Windows are 64-bit.
Ocaml version on my machine: 4.02.3, Ocaml version on VM: 4.01.0
Cygwin version on my machine and on VM: CYGWIN_NT-6.1-WOW64 1.7.27(0.271/5/3) 2013-12-09 11:57 i686 Cygwin
At the time Frama-C Magnesium was released, alt-ergo 1.01 did not exist yet. So when the WP manual for Magnesium mentioned compatibility with alt-ergo 0.99.1+, it could not foresee that there would be an incompatibility with the then future release of alt-ergo.
Fortunately, the next release (Aluminium) will be compatible with alt-ergo 1.01, so this should not be a problem in the future.
Meanwhile, you should be able to use alt-ergo 0.99.1.
Edit: Based on the error message and further details, it could be related to your Cygwin version, which seems relatively old, from 2013; yours is 1.7.27, while I'm using 2.4.1.