i installed gem5 simulator on ubuntu 14.04. then i used the youtube guide (https://www.youtube.com/watch?v=gd_DtxQD5kc) to run gem5 in full system mode in ARM architecture. first i downloaded arm-system-2011-08.tar.bz2 as mentioned in the video then i run below command:
build/ARM/gem5.opt configs/example/fs.py --disk-image=/home/morteza/full_system_images/disks/arm-ubuntu-natty-headless.img --kernel=/home/morteza/full_system_images/binaries/vmlinux.arm.smp.fb.2.6.38.8
but i encountered this output. can abybody please help me?
p.s: i added --kernel option and rename bootloader in /fulls_system_image/binaries from boot.arm to boot_emm.arm because of some errors about not finding bootloader and kernel. this is my final output which i brought hereunder. i' ll appreciate if anybody tell what is the problem.
OUTPUT:
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Jan 3 2020 05:49:20
gem5 started Jan 3 2020 17:16:17
gem5 executing on morteza-pc, pid 2499
command line: build/ARM/gem5.opt configs/example/fs.py --disk-image=/home/morteza/full_system_images/disks/arm-ubuntu-natty-headless.img --kernel=/home/morteza/full_system_images/binaries/vmlinux.arm.smp.fb.2.6.38.8
warn: Can only correctly generate a dtb for VExpress_GEM5_V1 platforms, unless custom hardware models have been equipped with generation functionality.
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
info: kernel located at: /home/morteza/full_system_images/binaries/vmlinux.arm.smp.fb.2.6.38.8
warn: Bootloader entry point 0x80000000 overriding reset address 0
system.vncserver: Listening for connections on port 5900
system.terminal: Listening for connections on port 3456
0: system.remote_gdb: listening for remote gdb on port 7000
info: Using bootloader at address 0x80000000
info: Using kernel entry physical address at 0x80008000
warn: DTB file specified, but no device tree support in kernel
**** REAL SIMULATION ****
warn: Existing EnergyCtrl, but no enabled DVFSHandler found.
info: Entering event queue # 0. Starting simulation...
warn: Device system.membus.badaddr_responder accessed by read to address 0x10009018 size=4
gem5.opt: build/ARM/cpu/simple/atomic.cc:418: virtual Fault AtomicSimpleCPU::readMem(Addr, uint8_t*, unsigned int, Request::Flags, const std::vector<bool>&): Assertion `!pkt.isError()' failed.
Program aborted at tick 30500
--- BEGIN LIBC BACKTRACE ---
build/ARM/gem5.opt(_Z15print_backtracev+0x15)[0x1d505e5]
build/ARM/gem5.opt(_Z12abortHandleri+0x36)[0x1d5a796]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f41e3962330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f41e1eacc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f41e1eb0028]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fbf6)[0x7f41e1ea5bf6]
/lib/x86_64-linux-gnu/libc.so.6(+0x2fca2)[0x7f41e1ea5ca2]
build/ARM/gem5.opt(_ZN15AtomicSimpleCPU7readMemEmPhj5FlagsImERKSt6vectorIbSaIbEE+0x538)[0x1e4eca8]
build/ARM/gem5.opt(_ZN17SimpleExecContext7readMemEmPhj5FlagsImERKSt6vectorIbSaIbEE+0x21)[0x1e5c5b1]
build/ARM/gem5.opt(_Z13readMemAtomicI11ExecContextjESt10shared_ptrI9FaultBaseEPT_PN5Trace10InstRecordEmRT0_5FlagsImE+0x64)[0x1972e14]
build/ARM/gem5.opt(_ZNK10ArmISAInst27LOAD_IMM_AY_PN_SN_UN_WN_SZ47executeEP11ExecContextPN5Trace10InstRecordE+0x12d)[0x14f95cd]
build/ARM/gem5.opt(_ZN15AtomicSimpleCPU4tickEv+0x428)[0x1e4da58]
build/ARM/gem5.opt(_ZN10EventQueue10serviceOneEv+0xa1)[0x1d55f51]
build/ARM/gem5.opt(_Z9doSimLoopP10EventQueue+0x38)[0x1d65fc8]
build/ARM/gem5.opt(_Z8simulatem+0xaae)[0x1d66dfe]
build/ARM/gem5.opt[0x1dbbd3d]
build/ARM/gem5.opt[0xe08e85]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x45f7)[0x7f41e3579be7]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d)[0x7f41e357b63d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x48d8)[0x7f41e3579ec8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d)[0x7f41e357b63d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x48d8)[0x7f41e3579ec8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d)[0x7f41e357b63d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x48d8)[0x7f41e3579ec8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d)[0x7f41e357b63d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7f41e357b772]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x563e)[0x7f41e357ac2e]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d)[0x7f41e357b63d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x48d8)[0x7f41e3579ec8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x80d)[0x7f41e357b63d]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7f41e357b772]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x79)[0x7f41e35755a9]
--- END LIBC BACKTRACE ---
Aborted (core dumped)
When I log in the Cisco Packet Tracer authentication page, as long as I click next, the program will automatically exit. If you start the program from the command line, it displays:
Starting Packet Tracer 7.2.2
/usr/local/bin/packettracer: line 8: 6290 Floating point exception(core dumped) ./PacketTracer7 "$#" > /dev/null 2>&1
After debugging with GDB, you will see:
Thread 1 "PacketTracer7" received signal SIGFPE, Arithmetic exception.
0x00007fffeede5ef4 in QFontEngineFT::averageCharWidth() const () from ./libQt5XcbQpa.so.5
I received a similar error and spent a lot of time troubleshooting, trying different qt5 library versions and installing a new libpng12 and such. Never got it to work. Then I found Cisco has released version 7.3.0 and it works fine.
FYI here is the exact error I received (in my dmesg) upon clicking the 'Next' button as you described:
[Sat Dec 21 21:18:22 2019] traps: PacketTracer7[12228] trap divide error ip:7f8ab1531ef4 sp:7ffd9d9710d0 error:0 in libQt5XcbQpa.so.5[7f8ab1475000+111000]
Iam facing JVM Crash cosistently while enabling hotdeploy (USING below java options on starting up JAVA_OPTS -Xmx4096m -XX:MetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=crash -XX:ThreadStackSize=512 -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=5 -XX:NewRatio=2 -XX:+UnlockDiagnosticVMOptions -XX:-UseLoopPredicate -Xdebug -Xrunjdwp:transport=dt_socket,address=$DEBUG_PORT,server=y,suspend=n -XX:NewRatio=2 -Dspringloaded.synchronize=true JAVA_OPTS=`echo $JAVA_OPTS -Dspringloaded.synchronize=true -javaagent:springloaded-1.2.1.jar -noverify
)
Environment : JDK 1.8 U 66, RHEL 6.7
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007faee9a1e27c, pid=27208, tid=140379827795712
#
# JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64 )
# Problematic frame:
# V [libjvm.so+0x35027c] Canonicalizer::do_If(If*)+0x1c
#
# Core dump written. Default location: core.27208
#
# An error report file with more information is saved as:
# hs_err_pid27208.log
# [ timer expired, abort... ]
I've noticed both -javaagent and -noverify in Java options list.
It looks like springloaded agent generates invalid bytecode, while the bytecode verification is explicitly turned off. No surprise, this may lead to unpredictable results including JVM crash.
This is not a JVM problem, but most likely a bug in springloaded agent. Try to remove -noverify option.
-XX:-TieredCompilation may also work around this particular problem, but don't expect application to work correctly if the bytecode fails to pass verification. It's better to stay away from the buggy agent libraries.
4.2.1 Crash in HotSpot Compiler Thread or Compiled Code
If the fatal error log indicates that the crash occurred in a compiler
thread, then it is possible (but not always the case) that you have
encountered a compiler bug. Similarly, if the crash is in compiled
code then it is possible that the compiler has generated incorrect
code.
In the case of the HotSpot Client VM (-client option), the compiler
thread appears in the error log as CompilerThread0. With the HotSpot
Server VM there are multiple compiler threads and these appear in the
error log file as CompilerThread0, CompilerThread1, and AdapterThread.
Below is a fragment of an error log for a compiler bug that was
encountered and fixed during the development of J2SE 5.0. The log file
shows that the HotSpot Server VM is used and the crash occurred in
CompilerThread1. In addition, the log file shows that the Current
CompileTask was the compilation of the java.lang.Thread.setPriority
method.
An unexpected error has been detected by HotSpot Virtual Machine:
:
Java VM: Java HotSpot(TM) Server VM (1.5-internal-debug mixed mode) :
--------------- T H R E A D ---------------
Current thread (0x001e9350): JavaThread "CompilerThread1" daemon
[_thread_in_vm, id=20]
Stack: [0xb2500000,0xb2580000), sp=0xb257e500, free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code) V [libjvm.so+0xc3b13c] :
Current CompileTask: opto: 11 java.lang.Thread.setPriority(I)V
(53 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread ) 0x00229930 JavaThread "Low
Memory Detector" daemon [_thread_blocked, id=21]
=>0x001e9350 JavaThread "CompilerThread1" daemon [_thread_in_vm, id=20] :
In this case there are two potential workarounds:
The brute force approach: change the configuration so that the application is run with the -client option to specify the HotSpot
Client VM.
Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation.
The first approach (to use the -client option) might be trivial to
configure in some environments. In others, it might be more difficult
if the configuration is complex or if the command line to configure
the VM is not readily accessible. In general, switching from the
HotSpot Server VM to the HotSpot Client VM also reduces the peak
performance of an application. Depending on the environment, this
might be acceptable until the actual issue is diagnosed and fixed.
The second approach (exclude the method from compilation) requires
creating the file .hotspot_compiler in the working directory of the
application. Below is an example of this file:
exclude java/lang/Thread setPriority
In general the format of this file is exclude CLASS METHOD, where
CLASS is the class (fully qualified with the package name) and METHOD
is the name of the method. Constructor methods are specified as
and static initializers are specified as .
Note - The .hotspot_compiler file is an unsupported interface. It is
documented here solely for the purposes of troubleshooting and finding
a temporary workaround.
Once the application is restarted, the compiler will not attempt to
compile any of the methods listed as excluded in the .hotspot_compiler
file. In some cases this can provide temporary relief until the root
cause of the crash is diagnosed and the bug is fixed.
In order to verify that the HotSpot VM correctly located and processed
the .hotspot_compiler file that is shown in the example above, look
for the following log information at runtime. Note that the file name
separator is a dot, not a slash.
Excluding compile: java.lang.Thread::setPriority
Source
Agree with #apangin, In the program you are doing bytecode intrumentation (-agent) but specifies -noverify. When verification is turned off, you may end up such crashes.
You should not use -noverify or -Xverify:none during byte code intrumentation.
For those of you unfamiliar with bytecode verification, it is simply part of the JVM's classloading process that checks the code for certain dangerous and disallowed behavior. You can (but shouldn't) disable this protection on many JVMs by adding -Xverify:none or -noverify to the Java command line. https://blogs.oracle.com/buck/entry/never_disable_bytecode_verification_in
I've been trying to build Mono 3.2.3 on Solaris 11 with no luck. I've made a few minor code changes and turned off configuration features to get to this point but now I'm stuck with mono crashing while trying to build System.dll. Any ideas?
MONO_PATH="./../../class/lib/basic:$MONO_PATH" /home/axsadm/mono-3.2.3/runtime/mono-wrapper ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
+ r=/home/axsadm/mono-3.2.3
+ MONO_CFG_DIR=/home/axsadm/mono-3.2.3/runtime/etc
+ PATH=/home/axsadm/mono-3.2.3/runtime/_tmpinst/bin:/usr/bin:/usr/sbin
+ MONO_SHARED_DIR=/home/axsadm/mono-3.2.3/runtime
+ export MONO_CFG_DIR MONO_SHARED_DIR PATH
+ [ -n '' ]
+ exec /home/axsadm/mono-3.2.3/libtool '--mode=execute' /home/axsadm/mono-3.2.3/mono/mini/mono --config /home/axsadm/mono-3.2.3/runtime/etc/mono/config ./../../class/lib/basic/basic.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/build -r:mscorlib.dll -optimize /noconfig -nowarn:618 -d:CONFIGURATION_2_0 -unsafe -resource:resources/Asterisk.wav -resource:resources/Beep.wav -resource:resources/Exclamation.wav -resource:resources/Hand.wav -resource:resources/Question.wav -target:library -out:../../class/lib/build/tmp/System.dll #System.dll.sources
* Assertion at threads.c:1001, condition `info' not met
Native stacktrace:
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_handle_native_sigsegv+0x1b8 [0x187c58]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'sigabrt_signal_handler+0xa0 [0x1ed97c]
/lib/libc.so.1'__sighndlr+0xc [0xff0254f0]
/lib/libc.so.1'call_user_handler+0x370 [0xff018e50]
/lib/libc.so.1'sigacthandler+0x58 [0xff019040]
/lib/libc.so.1'_lwp_kill+0x8 [0xff029fa0]
/lib/libc.so.1'abort+0xc8 [0xfefaac2c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_g_logv+0x174 [0x3d5454]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'monoeg_assertion_message+0x38 [0x3d54e8]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach_full+0x2bc [0x2dc650]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_thread_attach+0x10 [0x2dc37c]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_runtime_init+0x23c [0x314034]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mini_init+0x1a60 [0x77158]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main+0x232c [0x1457a4]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'mono_main_with_options+0x48c [0x5fa30]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'main+0x2c [0x5fa74]
/home/axsadm/mono-3.2.3/mono/mini/mono-boehm'_start+0x5c [0x5f3e4]
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
gmake[8]: *** [../../class/lib/build/tmp/System.dll] Abort (core dumped)
Configuration:
Engine:
GC: included Boehm
TLS: pthread
SIGALTSTACK: no
Engine: Building and using the JIT
oprofile: no
BigArrays: no
DTrace: no
LLVM Back End: no (dynamically loaded: no)
Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes
MonoDroid: no
MonoTouch: no
JNI support: IKVM Native
libgdiplus: assumed to be installed
zlib: system zlib
This might be a bit late, but for me I had more luck using the external Boehm GC as opposed to the bundled/included one.
./autogen.sh --prefix=/usr --disable-dtrace --with-sgen=no --with-gc=boehm
This seemed to work OK for Solaris 10 and 11 on Intel. I'm still working on SPARC!
Good luck,
Steve
I have written a jvmti agent to trace method invocations. I code it with C and jvmti and jni functions. Our os is Fedora 15 and the agent is compiled into a .so file. When I test it with a non-trivial java program, it crashes and gives the following error message:
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x4e8e4e28, pid=24294, tid=3065949040.
JRE version: 6.0_32-b05.
Java VM: Java HotSpot (TM) Server VM (20.7-b02 mixed mode linux-x86).
**Problematic frame:
C [libc.so.6+0x7ae68] strcpy+0x18.**
IGSEGV is an abbreviation for Signal Segmentation Violation. On
POSIX-compliant platforms, SIGSEGV is the signal sent to a process
when it makes an invalid memory reference, or segmentation fault.
You have to check the pointers in your JVMTI agent. In all probability you make some unclean pointer operations.