From: Eric M. <eri...@fr...> - 2011-07-20 12:51:24
|
Hi, On SBCL 1.0.50 on Linux/AMD64: * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x))) FOO * (foo #C(1.0 2.0)) CORRUPTION WARNING in SBCL pid 24208(tid 140737353934592): Memory fault at 0 (pc=0x100304f85f, sp=0x7ffff6d67520) The integrity of this image is possibly compromised. Continuing with fingers crossed. 0] backtrace 0: (SB-SYS:MEMORY-FAULT-ERROR) 1: ("foreign function: call_into_lisp") 2: ("foreign function: post_signal_tramp") 3: (FOO :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE) 4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO #C(1.0 2.0)) #<NULL-LEXENV>) 5: (EVAL (FOO #C(1.0 2.0))) -- Eric Marsden |
From: Paul K. <pv...@pv...> - 2011-07-20 13:46:27
|
On 2011-07-20, at 8:50 AM, Eric Marsden wrote: > Hi, > > On SBCL 1.0.50 on Linux/AMD64: > > * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x))) > FOO > * (foo #C(1.0 2.0)) > CORRUPTION WARNING in SBCL pid 24208(tid 140737353934592): > Memory fault at 0 (pc=0x100304f85f, sp=0x7ffff6d67520) > The integrity of this image is possibly compromised. > Continuing with fingers crossed. > 0] backtrace > 0: (SB-SYS:MEMORY-FAULT-ERROR) > 1: ("foreign function: call_into_lisp") > 2: ("foreign function: post_signal_tramp") > 3: (FOO :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE) > 4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO #C(1.0 2.0)) #<NULL-LEXENV>) > 5: (EVAL (FOO #C(1.0 2.0))) This looks like an instruction encoding error. DISASSEMBLE barfs on FOO, and gdb reveals: 0x1003077ee8: popq 0x8(%rbp) 0x1003077eeb: lea -0x30(%rbp),%rsp 0x1003077eef: cmp $0x8,%rcx 0x1003077ef3: jne 0x1003077f34 0x1003077ef5: mov %rdx,%rcx 0x1003077ef8: mov %ecx,%eax 0x1003077efa: and $0xf,%al 0x1003077efc: cmp $0xf,%al 0x1003077efe: jne 0x1003077f3a 0x1003077f00: mov -0xf(%rcx),%al 0x1003077f03: cmp $0x26,%al 0x1003077f05: jne 0x1003077f3a 0x1003077f07: mov %rcx,%rax 0x1003077f0a: movq -0x7(%rax),%xmm0 0x1003077f0f: cmpeqps 0x3a(%rip),%xmm0 # 0x1003077f51 *** 0x1003077f17: movmskps %xmm0,%rax 0x1003077f1b: cmp $0xf,%rax 0x1003077f1f: mov $0x20100017,%edx 0x1003077f24: mov $0x2010004f,%r11d 0x1003077f2a: cmove %r11,%rdx 0x1003077f2e: mov %rbp,%rsp 0x1003077f31: clc 0x1003077f32: pop %rbp 0x1003077f33: retq That's right, 0x1003077f51. The values are actually at 0x1003077f50. Paul Khuong |
From: Paul K. <pv...@pv...> - 2011-07-22 03:12:41
|
On 2011-07-20, at 8:50 AM, Eric Marsden wrote: > Hi, > > On SBCL 1.0.50 on Linux/AMD64: > > * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x))) > FOO > * (foo #C(1.0 2.0)) It's indeed a bug in our encoding of RIP-relative EAs (a couple SSE instructions (shuffles and comparisons) have the interesting characteristic of not having the reg/mem operand as the last field). I can fix the assembler, but I have no clue how to get the disassembler right. Paul Khuong |
From: <lut...@fr...> - 2011-07-22 13:01:58
|
Hi, Paul Khuong wrote: > On 2011-07-20, at 8:50 AM, Eric Marsden wrote: > >> Hi, >> >> On SBCL 1.0.50 on Linux/AMD64: >> >> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x))) >> FOO >> * (foo #C(1.0 2.0)) > > It's indeed a bug in our encoding of RIP-relative EAs (a couple SSE > instructions (shuffles and comparisons) have the interesting > characteristic of not having the reg/mem operand as the last field). > I can fix the assembler, but I have no clue how to get the > disassembler right. I volunteer to do the disassembler part. I'll wait for the assembler part to be done and base a patch on that as some of the changes will need to be textually very near to the assembler part. Greetings, Lutz |
From: Paul K. <pv...@pv...> - 2011-07-22 16:01:45
|
On 2011-07-22, at 9:01 AM, Lutz Euler wrote: > > Paul Khuong wrote: > >> On 2011-07-20, at 8:50 AM, Eric Marsden wrote: >> >>> Hi, >>> >>> On SBCL 1.0.50 on Linux/AMD64: >>> >>> * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x))) >>> FOO >>> * (foo #C(1.0 2.0)) >> >> It's indeed a bug in our encoding of RIP-relative EAs (a couple SSE >> instructions (shuffles and comparisons) have the interesting >> characteristic of not having the reg/mem operand as the last field). >> I can fix the assembler, but I have no clue how to get the >> disassembler right. > > I volunteer to do the disassembler part. I'll wait for the assembler > part to be done and base a patch on that as some of the changes will > need to be textually very near to the assembler part. The assembler fix has just been committed (9d2548c Correct RIP-relative offset for strange x86-64 instructions). The disassembler bug has been around for almost two years, and no one's complained yet, so we must be lucky (: Paul Khuong |
From: Paul K. <pv...@pv...> - 2011-07-22 15:58:08
|
On 2011-07-20, at 8:50 AM, Eric Marsden wrote: > Hi, > > On SBCL 1.0.50 on Linux/AMD64: > > * (defun foo (x) (= #C(2.0 3.0) (the (complex single-float) x))) > FOO > * (foo #C(1.0 2.0)) > CORRUPTION WARNING in SBCL pid 24208(tid 140737353934592): > Memory fault at 0 (pc=0x100304f85f, sp=0x7ffff6d67520) > The integrity of this image is possibly compromised. > Continuing with fingers crossed. > 0] backtrace > 0: (SB-SYS:MEMORY-FAULT-ERROR) > 1: ("foreign function: call_into_lisp") > 2: ("foreign function: post_signal_tramp") > 3: (FOO :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE) > 4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO #C(1.0 2.0)) #<NULL-LEXENV>) > 5: (EVAL (FOO #C(1.0 2.0))) Fixed in 9d2548c Correct RIP-relative offset for strange x86-64 instructions. Thanks for the nice report! Paul Khuong |
From: Eric M. <eri...@fr...> - 2011-08-23 11:40:27
|
Hi, The fix for this bug seems to have been incomplete. ,---- | * (lisp-implementation-version) | "1.0.51.6-d648683" | * (funcall (lambda (x) | (declare (type (complex single-float) x)) | (+ #C(0.0 1.0) x)) #C(1.0 2.0)) | CORRUPTION WARNING in SBCL pid 11171(tid 140737353930496): | Memory fault at 0 (pc=0x100473a8ec, sp=0x7ffff6d67520) | The integrity of this image is possibly compromised. | Continuing with fingers crossed. | debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR: | Unhandled memory fault at #x0. | 0] backtrace | 0: (SB-SYS:MEMORY-FAULT-ERROR) | 1: ("foreign function: call_into_lisp") | 2: ("foreign function: post_signal_tramp") | 3: ((LAMBDA (X)) :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE) `---- (Still on Linux/AMD64). -- Eric Marsden |
From: Paul K. <pv...@pv...> - 2011-08-23 20:20:11
|
On 2011-08-23, at 7:39 AM, Eric Marsden wrote: > Hi, > > The fix for this bug seems to have been incomplete. > > ,---- > | * (lisp-implementation-version) > | "1.0.51.6-d648683" > | * (funcall (lambda (x) > | (declare (type (complex single-float) x)) > | (+ #C(0.0 1.0) x)) #C(1.0 2.0)) > | CORRUPTION WARNING in SBCL pid 11171(tid 140737353930496): > | Memory fault at 0 (pc=0x100473a8ec, sp=0x7ffff6d67520) > | The integrity of this image is possibly compromised. > | Continuing with fingers crossed. > | debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR: > | Unhandled memory fault at #x0. > | 0] backtrace > | 0: (SB-SYS:MEMORY-FAULT-ERROR) > | 1: ("foreign function: call_into_lisp") > | 2: ("foreign function: post_signal_tramp") > | 3: ((LAMBDA (X)) :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE) > `---- That was actually an unrelated code generation bug. Should be fixed in HEAD. Thanks for the report again, Paul Khuong |