I'm working on an RCP java project using swt/jface in the IHM, i'm encountring a serious issue causing the crash of the app.
I tried inspecting the pid file but the last methods in the stack in the pid file are different.
I increased the xmx and xms but the crashs remain, i look for an index helping me solve it but no way.
bellow a snap from the pid file
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000005f8c04fa, pid=5268, tid=0x00000000000008c0
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 1.8.0_102-b14)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode windows-amd64 compressed oops)
> # Problematic frame:
> # C 0x000000005f8c04fa
> #
> # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.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 (0x000000000226f800): JavaThread "main"
> [_thread_in_native, id=2240,
> stack(0x00000000026a0000,0x00000000027a0000)]
>
> siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000013
>
> Registers: RAX=0x0000000000040b3e, RBX=0x0000000000000002,
> RCX=0x0000000040b3ed30, RDX=0x0000000000000002 RSP=0x000000000279a700,
> RBP=0x0000000040b3e000, RSI=0x0000000040b3e000, RDI=0x0000000000000000
> R8 =0x0000000000000001, R9 =0x0000000000000001,
> R10=0x0000000004deb3c9, R11=0x0000000004deb398 R12=0x00000000609a8730,
> R13=0x0000000000000000, R14=0x0000000000000001, R15=0x0000000000000000
> RIP=0x000000005f8c04fa, EFLAGS=0x0000000000010202
>
> Top of Stack: (sp=0x000000000279a700) 0x000000000279a700:
> 000000000279a848 0000000000000000 0x000000000279a710:
> 000000000226f800 000000000279a7d8 0x000000000279a720:
> 000000000226f800 000000000279a808 0x000000000279a730:
> 0000000000000000 0000000000470000 0x000000000279a740:
> 000000000279a7d8 000000005f8bf2e3 0x000000000279a750:
> 0000000000000002 0000000040b3ed30 0x000000000279a760:
> 000000000279a7f0 0000000000470000 0x000000000279a770:
> 0000000000000000 0000000004deb447 0x000000000279a780:
> 0000000024385638 00000006dce5dbb0 0x000000000279a790:
> 0000000000421054 0000000002c06f44 0x000000000279a7a0:
> 0000000000000002 0000000004e7aef4 0x000000000279a7b0:
> 0000000000000000 0000000000000000 0x000000000279a7c0:
> 0000000036bb84e0 0000000000000000 0x000000000279a7d0:
> 000000000279a868 00000006dd0f16a0 0x000000000279a7e0:
> 00000006dd0f16a0 0000000002a77f10 0x000000000279a7f0:
> 000000000279a868 0000000002a77f10
>
> Instructions: (pc=0x000000005f8c04fa) 0x000000005f8c04da: 81 e3 ff
> 07 00 00 48 03 db 49 39 b4 dc d0 08 00 0x000000005f8c04ea: 00 75 28
> 49 8b 9c dc d8 08 00 00 48 85 db 74 20 0x000000005f8c04fa: 0f b6 43
> 11 41 3b c0 75 17 41 83 f8 01 0f 85 80 0x000000005f8c050a: 01 00 00
> ff 43 18 e9 78 01 00 00 48 8b 5c 24 50
>
>
> Register to memory mapping:
>
> RAX=0x0000000000040b3e is an unknown value RBX=0x0000000000000002 is
> an unknown value RCX=0x0000000040b3ed30 is an unknown value
> RDX=0x0000000000000002 is an unknown value RSP=0x000000000279a700 is
> pointing into the stack for thread: 0x000000000226f800
> RBP=0x0000000040b3e000 is an unknown value RSI=0x0000000040b3e000 is
> an unknown value RDI=0x0000000000000000 is an unknown value R8
> =0x0000000000000001 is an unknown value R9 =0x0000000000000001 is an unknown value R10=0x0000000004deb3c9 is at entry_point+73 in
> (nmethod*)0x0000000004deb210 R11=0x0000000004deb398 is at
> entry_point+24 in (nmethod*)0x0000000004deb210 R12=0x00000000609a8730
> is an unknown value R13=0x0000000000000000 is an unknown value
> R14=0x0000000000000001 is an unknown value R15=0x0000000000000000 is
> an unknown value
>
>
> Stack: [0x00000000026a0000,0x00000000027a0000],
> sp=0x000000000279a700, free space=1001k Native frames: (J=compiled
> Java code, j=interpreted, Vv=VM code, C=native code) C
> 0x000000005f8c04fa C 0x000000005f8bf2e3 C 0x0000000004deb447
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 10363
> org.eclipse.swt.internal.win32.OS.HeapAlloc(JII)J (0 bytes) #
> 0x0000000004deb3c9 [0x0000000004deb380+0x49] j
> org.eclipse.swt.widgets.CoolBar.createItem(Lorg/eclipse/swt/widgets/CoolItem;I)V+114
> j
> org.eclipse.swt.widgets.CoolItem.<init>(Lorg/eclipse/swt/widgets/CoolBar;I)V+17
> j
> fr.ifp.temisflow.api.basintools.ui.ui.widget.CoolItemFactory.createCoolItem(ILorg/eclipse/swt/widgets/Control;II)Lorg/eclipse/swt/widgets/CoolItem;+58
and my VM arguments et environment variables are:
> VM Arguments: jvm_args:
> -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:58325 -Xms400m -Xmx4000m -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+AggressiveOpts -Dfile.encoding=Cp1252 java_command: org.eclipse.equinox.launcher.Main -launcher
> -os win32 -ws win32 -arch x86_64 -nl en_GB -consoleLog java_class_path (initial):
> C:\Users\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar
> Launcher Type: SUN_STANDARD
>
> Environment Variables: PATH=C:/Program
> Files/Java/jre1.8.0_102/bin/server;C:/Program
> Files/Java/jre1.8.0_102/bin;C:/Program
> Files/Java/jre1.8.0_102/lib/amd64;C:\Program Files (x86)\Common
> Files\Intel\Shared Libraries\redist\intel64\mpirt;C:\Program Files
> (x86)\Common Files\Intel\Shared
> Libraries\redist\intel64\compiler;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program
> Files (x86)\WinMerge;C:\Program Files (x86)\Common
> Files\SYSTEM\MSMAPI\1036;C:\Users\eclipse;
> USERNAME=** OS=Windows_NT PROCESSOR_IDENTIFIER=Intel64 Family 6
> Model 26 Stepping 5, GenuineIntel
>
>
>
> --------------- S Y S T E M ---------------
>
> OS: Windows 7 , 64 bit Build 7601 (6.1.7601.23572)
>
> CPU:total 4 (4 cores per cpu, 2 threads per core) family 6 model 26
> stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1,
> sse4.2, popcnt, ht, tsc, tscinvbit, tscinv
>
> Memory: 4k page, physical 12580408k(5019496k free), swap
> 25158956k(16067112k free)
>
> vm_info: Java HotSpot(TM) 64-Bit Server VM (25.102-b14) for
> windows-amd64 JRE (1.8.0_102-b14), built on Jun 22 2016 13:15:21 by
> "java_re" with MS VC++ 10.0 (VS2010)
i also looked through the log in the the .metadata in the workspace but no logs during the crash.
Is there any possible solution or steps or rule skout to solve the java fatal error in java 8 ?
Check your RAM.
I was suffering that very same error EXCEPTION_ACCESS_VIOLATION (0xc0000005), a couple times a day, for weeks, until I run a memory diagnostics tool and found that one of my RAM modules was faulty.
Reference: JVM Crashing EXCEPTION_ACCESS_VIOLATION (0xc0000005)
ANNIVERSARY EDIT: It's been a bit over a year since I solved the problem by replacing the faulty RAM module. Now, for a couple weeks I've been experiencing the same error, again. I just run the memory diagnostics tool and BAM! It detected memory errors, again. So, seriously people: check your RAM.
Related
I make an elf file from an intel-hex file using riscv64-unknown-elf-objcopy.
exact command:
riscv64-unknown-elf-objcopy -O elf32-littleriscv --set-start 0x10000000 --rename-section .sec1=.text image32.ihex image32.elf
the result looks like this:
$ riscv64-unknown-elf-readelf image32.elf -h
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x10000000
Start of program headers: 0 (bytes into file)
Start of section headers: 136148 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 7
My purpose is to execute it using 'Spike'.
Spike does not accept my elf file:
spike --isa=RV32IM --priv=MU -m0x10000000:0x00200000 --real-time-clint image32.elf
spike: ../fesvr/elfloader.cc:36: std::map<std::__cxx11::basic_string<char>, long unsigned int> load_elf(const char*, memif_t*, reg_t*): Assertion `IS_ELF_EXEC(*eh64)' failed.
It does accept elf files with the following header:
$ riscv64-unknown-elf-readelf ok.elf -h
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: RISC-V
Version: 0x1
Entry point address: 0x10000000
Start of program headers: 52 (bytes into file)
Start of section headers: 54672 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 23
Section header string table index: 22
I guess I need to change the "Type" field from "REL" to "EXEC", but I do not see any option for that in objcopy.
This post suggests that the following sequence might do what you want:
riscv64-unknown-elf-objcopy -I ihex -O binary image32.ihex image32.bin
riscv64-unknown-elf-objcopy -I binary -O riscv64-unknown-elf image32.bin image32.elf
But I am just guessing :-(
I have a simple nasm code:
test.nasm
section .text
global _start
_start:
jmp _start
ret
I build it as below:
nasm -f elf64 test.nasm -o test.o
ld test.o -o test -pie
Then I tried to run it:
./test
It gives me this:
bash: ./test: No such file or directory
So I checked the file header:
readelf -h test
It shows this:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file) <====== NOT an executable
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1f0
Start of program headers: 64 (bytes into file)
Start of section headers: 4616 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 12
Section header string table index: 11
But I can easily create a position independent executable with GCC for below program:
test2.c
#include <stdio.h>
void main(void)
{
printf("hello, pie!\n");
}
I build it with:
gcc test2.c -o test2 -pie
It runs like this:
hello, pie!
So how can I create a position independent executable with nasm and ld rather than a shared object?
ADD 1
I checked the test2 ELF header. It is also a shared object. So it may not be the problem. (Thanks to #Nate Eldredge)
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file) <===== ALSO a shared object
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x530
Start of program headers: 64 (bytes into file)
Start of section headers: 6440 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 9
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 28
So how can I use ld to get a position-independent executable from the object file generated with nasm?
I've built a kernel on x86_64 (kernel ver 3.18.22) with kmemcheck enabled.
Relevant configs:
# grep KMEMCHECK /boot/config-3.18.22
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_KMEMCHECK=y
CONFIG_KMEMCHECK_DISABLED_BY_DEFAULT=y
# CONFIG_KMEMCHECK_ENABLED_BY_DEFAULT is not set
# CONFIG_KMEMCHECK_ONESHOT_BY_DEFAULT is not set
CONFIG_KMEMCHECK_QUEUE_SIZE=64
CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT=5
CONFIG_KMEMCHECK_PARTIAL_OK=y
# CONFIG_KMEMCHECK_BITOPS_OK is not set
#
Wrote a quick kernel module to test kmemcheck catching uninitialized slab memory accesses. The function in question that runs this simple test case:
static int slab_test(void)
{
void *kbuf;
kbuf = kmalloc(512, GFP_KERNEL);
if (!kbuf) {
pr_warn("out of memory!");
return -ENOMEM;
}
pr_info("### slab_test: kbuf=%p\n", kbuf);
print_hex_dump_bytes("### ", DUMP_PREFIX_ADDRESS, kbuf, 32);
kfree(kbuf);
return 0;
}
I enable kmemcheck, insert the module and call the above function, log the output - all via a small wrapper script below:
# cat tst.sh
MOD=kmemchk_test
echo 0 > /proc/sys/kernel/kmemcheck
dmesg -C
rmmod ${MOD} 2>/dev/null
echo 1 > /proc/sys/kernel/kmemcheck
insmod ${MOD}.ko
sleep 1
echo 0 > /proc/sys/kernel/kmemcheck
dmesg > out.txt
#
My problem is this: kmemcheck does not seem to catch the uninitialized memory access at all! Here's the output:
# dmesg
--snip--
kern :info : [ +0.000005] ### slab_test: kbuf=ffff88003ccc8000
kern :debug : [ +0.000003] ### ffff88003ccc8000: 00 8c cc 3c 00 88 ff ff 75 6c 65 2f 6b 6d 65 6d ...<....ule/kmem
kern :debug : [ +0.000003] ### ffff88003ccc8010: 63 68 6b 5f 74 65 73 74 00 41 43 54 49 4f 4e 3d chk_test.ACTION=
#
Any idea why? TIA..
the question is to print the answer for b+c-d
but i m not getting the anwser...help!!! instead of getting 12 i m getting 49
[here b=10 c=7 d= 5]
C:\>debug
-e 2000
0AFC:2000 0D.10 0A.7 36.5
-a 1000
0AFC:1000 mov al, [2000]
0AFC:1003 add al, [2001]
0AFC:1007 sub al, [2002]
0AFC:100B mov [2003], al
0AFC:100E hlt
0AFC:100F
-g 1000 100F
Program terminated normally
-d 2000 2003
0AFC:2000 10 07 05 49 ...I
-g= 1000 100F
mipsisa64-octeon-elf-gcc obj/zxmd_main.o obj/zxmd_mproc.o obj/zxmd_init.o obj/zxmd_pcie.o obj/libcvm-common.a obj/libcvm-pci-drv.a obj/libcvmhfao.a obj/libocteon-hfa.a /home/jianxi/Juson/JusonFlow/sdk/OCTEON-SDK/components/hfa/lib-octeon/pp/octeon/se/libpp.a obj/libcvmx.a obj/libzxexe.a obj/libfdt.a -mfix-cn63xxp1 -march=octeon2 -o cn63hw1.bin
gcc complain:
obj/libzxexe.a(zxmx_tim.o): In function `zxmx_init_tim':
/home/jianxi/Juson/JusonFlow/libexec/zxmx_tim.c:47: undefined reference to `cvmx_tim_setup'
But cvmx_tim_setup can be found in libcvmx.a:
[jianxi#jianxi obj]$ readelf -h libcvmx.a | grep "cvmx-tim.o" -A21
File: libcvmx.a(cvmx-tim.o)
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 13424 (bytes into file)
Flags: 0x808d4001, noreorder, octeon2, eabi64, mips64r2
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 33
Section header string table index: 30
[jianxi#jianxi obj]$ readelf -s cvmx-tim.o
27: 00000000 92 FUNC GLOBAL DEFAULT 1 cvmx_tim_start
28: 00000000 40 OBJECT GLOBAL DEFAULT 16 cvmx_tim
29: 00000060 56 FUNC GLOBAL DEFAULT 1 cvmx_tim_stop
30: 00000098 276 FUNC GLOBAL DEFAULT 1 cvmx_tim_shutdown
31: 000001b0 752 FUNC GLOBAL DEFAULT 1 cvmx_tim_setup
32: 00000000 0 NOTYPE GLOBAL DEFAULT UND cvmx_clock_get_rate
33: 00000000 0 NOTYPE GLOBAL DEFAULT UND cvmx_bootmem_alloc
34: 00000000 0 NOTYPE GLOBAL DEFAULT UND memset
35: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
36: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
When i added cvmx-tim.o in the command , gcc will be executed successfully：
mipsisa64-octeon-elf-gcc obj/cvmx-tim.o obj/zxmd_main.o obj/zxmd_mproc.o obj/zxmd_init.o obj/zxmd_pcie.o obj/libcvm-common.a obj/libcvm-pci-drv.a obj/libcvmhfao.a obj/libocteon-hfa.a /home/jianxi/Juson/JusonFlow/sdk/OCTEON-SDK/components/hfa/lib-octeon/pp/octeon/se/libpp.a obj/libcvmx.a obj/libzxexe.a obj/libfdt.a -mfix-cn63xxp1 -march=octeon2 -o cn63hw1.bin
And if put obj/libcvmx.a in front of obj/zxmd_main.o , gcc will report more errors.
Why gcc can not find cvmx-tim.o in the libcvmx.a?
The order of *.o will cause problems?
It's the order of the libraries:
obj/libcvmx.a obj/libzxexe.a
by the time the linker searches obj/libzxexe.a it has already processed obj/libcvmx.a - it won't search it again for anything that was not already been pulled in when obj/libcvmx.a was processed the first time around.
Change the order of those libraries to:
obj/libzxexe.a obj/libcvmx.a
Besides changing the order of the libraries, you can also force the cvmx_tim_setup to be a marked as 'undefined' symbol in command line. If the symbol is known to be required, then the linker will be on the lookout for it and remember the first library defining it.
add this flag to gcc command: -Wl,--undefined=cvmx_tim_setup
Additionally you can also experiment with --start-group and --end-group in gcc. --start-group (list of binaries to link) --end-group. This will allow a full circular closure for searches. But will cost some link performance.
Ref:
http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking
Paxym