Status fields:
| creation_ts: | 2008-07-02 16:37 |
|---|---|
| component: | jit |
| version: | default branch |
| rep_platform: | All |
| op_sys: | All |
| bug_status: | RESOLVED |
| resolution: | FIXED |
| reporter: | twisti@complang.tuwien.ac.at |
Since we are using trap instructions to invoke patcher functions, we can hit a race condition here in the following situation: 2 threads are running on 2 CPUs. The first thread hits the trap and executes the patcher function. The second thread hits the trap instruction and right after the trap for the second thread is handled by the kernel, the first thread patches back the original instruction. The second thread sees then the original instruction in the signal handler instead of the trap instruction and most likely aborts, since it can't read the required data from the trap instruction. A solution would be to check in the signal handler if there is a trap instruction at the faulting position (PC) and if not, check the patcher list if there was a patcher trap at this PC which has already been patched. If that is true, simply return.
Cool find! This could be the reason for most crashes I witnessed in dacapo lusearch and xalan.
cacaojvm.org
patching in org.apache.axis.encoding.TypeMappingRegistryImpl.<init>(Z)V PUBLIC (mono)
(impl) at 0x44240bf0
patcher function = -UNKNOWN PATCHER FUNCTION- <0x40239f60>
machine code before = e7f007f0 at 0x44240bf0 (disassembler disabled)
machine code after = e51c002c at 0x44240bf0 (disassembler disabled)
...
LOG: [0x00004000] md_signal_handler_sigill: Unknown illegal instruction 0xe51c002c at
0x44240bf0
LOG: [0x00004000] Aborting...
To fix this bug properly I have to change some of the JIT ports (alpha, mips, maybe others too) to use a dedicated signal (e.g. SIGILL) for patcher traps. I'm working on it.
Fix for ARM: http://mips.complang.tuwien.ac.at/hg/cacao/rev/cc536a1ac45c
*** Bug 73 has been marked as a duplicate of this bug. ***
*** Bug 74 has been marked as a duplicate of this bug. ***
*** Bug 75 has been marked as a duplicate of this bug. ***
*** Bug 76 has been marked as a duplicate of this bug. ***
Fix for powerpc64: http://mips.complang.tuwien.ac.at/hg/cacao/rev/a470a2a8360d
Fix for powerpc: http://mips.complang.tuwien.ac.at/hg/cacao/rev/05da7a4ba56b
Created an attachment (id=52) make fp-abi hack compatible with neon hardware Attached is a patch that modifies the hacks and replaces them with instructions that are available on armv7 /w neon.
Fix for x86_64: http://mips.complang.tuwien.ac.at/hg/cacao/rev/7e6eef2b4c94
Fix for i386: http://mips.complang.tuwien.ac.at/hg/cacao/rev/2a4bca2e3f35 x86_64 & i386 are Linux only so far. Will need to be transferred to the other md-os.c as well.
As the comment mentions, this should be moved to the generic patcher handler function. It would be better to implement it there and ifdef it away for the archs which do not have the necessary support functions yet. That way it will be less work.
Agreed, that would be much better. It has been not done that way yet, though.
The fixes have been done like this because they should be ported to cacao-1.0.x too.
*** Bug 44 has been marked as a duplicate of this bug. ***
This is the clean-solution fix for the given problem on the trunk, please review: http://mips.complang.tuwien.ac.at/hg/cacao/rev/96f53095598b
The new-trap-decoding branch was merged back onto default. Bug is hereby closed. http://mips.complang.tuwien.ac.at/hg/cacao/rev/e651482cd9e7
| date: | 2008-10-01 16:11 |
|---|---|
| desc: | make fp-abi hack compatible with neon hardware |
| type: | text/plain |
| download: | neon-compat.diff |