[Sbcl-help] Bug under WSL when using vop assembler

[Andrew Sengul]

Hello, I'm encountering a strange bug when trying to run kernels
generated using April's new vop-based JIT assembler. The trace is below.
This is happening when running SBCL in Linux under WSL in Windows; I
haven't encountered it when running on a native Linux install. Could
this problem have something to do with WSL? Thanks,

Andrew

failed AVER: (SB-X86-64-ASM::ACCUMULATOR-P SB-X86-64-ASM::DST)

This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
   [Condition of type SB-INT:BUG]

Restarts:
 0: [ABORT] Abort compilation.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] abort thread (#<THREAD "worker" RUNNING {1013B5D023}>)

Backtrace:
  0: ((FLET SB-X86-64-ASM::EMIT* :IN
"SYS:SRC;COMPILER;X86-64;INSTS.LISP") #<SB-ASSEM:SEGMENT {1015304143}>
:DWORD RCX 6)
  1: (SB-ASSEM::%ASSEMBLE #<SB-ASSEM:SEGMENT {1015304143}>
(#<SB-ASSEM::STMT IGNORE {10152F9D13}> . #<SB-ASSEM::STMT .ALIGN
{10153042F3}>))
  2: (SB-ASSEM:ASSEMBLE-SECTIONS #S(SB-ASSEM::ASMSTREAM :DATA-SECTION
(#<SB-ASSEM::STMT IGNORE {10152F9D13}> . #<SB-ASSEM::STMT .ALIGN
{10153042F3}>) :CODE-SECTION (#1=#<SB-ASSEM::STMT IGNORE {10152F9D63}>..
  3: (SB-C::GENERATE-CODE #<SB-C:COMPONENT :NAME (LAMBDA (VARRAY::A
VARRAY::B VARRAY::C VARRAY::D) :IN "/tmp/slimevhCUGK.fasl") {10152E7A33}>)
  4: (SB-C::%COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LAMBDA (VARRAY::A
VARRAY::B VARRAY::C VARRAY::D) :IN "/tmp/slimevhCUGK.fasl") {10152E7A33}>)
  5: (SB-C::COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LAMBDA (VARRAY::A
VARRAY::B VARRAY::C VARRAY::D) :IN "/tmp/slimevhCUGK.fasl") {10152E7A33}>)
  6: (SB-C::%COMPILE (LAMBDA (VARRAY::A VARRAY::B VARRAY::C VARRAY::D)
(DECLARE (OPTIMIZE # #)) (VARRAY::VOP-PH VARRAY::A VARRAY::B VARRAY::C
VARRAY::D)) #<SB-C::CORE-OBJECT {10152E29E3}> :NAME NIL :PATH (..
  7: ((FLET "LAMBDA0" :IN "SYS:SRC;COMPILER;TARGET-MAIN.LISP"))
  8: ((FLET SB-C::WITH-IT :IN SB-C::%WITH-COMPILATION-UNIT))
  9: (SB-C:COMPILE-IN-LEXENV (LAMBDA (VARRAY::A VARRAY::B VARRAY::C
VARRAY::D) (DECLARE (OPTIMIZE # #)) (VARRAY::VOP-PH VARRAY::A VARRAY::B
VARRAY::C VARRAY::D)) #<NULL-LEXENV> NIL NIL NIL NIL NIL)
 10: (COMPILE NIL (LAMBDA (VARRAY::A VARRAY::B VARRAY::C VARRAY::D)
(DECLARE (OPTIMIZE # #)) (VARRAY::VOP-PH VARRAY::A VARRAY::B VARRAY::C
VARRAY::D)))
 11: (SB-EVAL::EVAL-NEXT-LET*-BINDING ((#:NEW1 COMPILE NIL (QUOTE #)))
NIL #<SB-EVAL::ENV {10152E1133}> #<CLOSURE (LAMBDA (SB-EVAL::ENV) :IN
SB-EVAL::EVAL-LET*) {10152E11AB}>)
 12: (SB-EVAL:EVAL-IN-NATIVE-ENVIRONMENT (PROGN (SB-C:DEFKNOWN
VARRAY::VOP-PH (#1=# #1# #1# #1#) #1# (SB-C:FOLDABLE SB-ASSEM:FLUSHABLE
SB-C:MOVABLE) :OVERWRITE-FNDB-SILENTLY ...) (UNLESS (FBOUNDP #) (PROCL..
 13: (EVAL (PROGN (SB-C:DEFKNOWN VARRAY::VOP-PH (#1=# #1# #1# #1#) #1#
(SB-C:FOLDABLE SB-ASSEM:FLUSHABLE SB-C:MOVABLE) :OVERWRITE-FNDB-SILENTLY
...) (UNLESS (FBOUNDP #) (PROCLAIM #) (SETF #2=# #)) (SB-C:DE..
 14: ((:METHOD VARRAY::RENDER (VARRAY)) #<VADER-TURN {1014B16283}>
:MAY-BE-DEFERRED T) [fast-method]
 15: ((LAMBDA NIL :IN "/mnt/c/d/j.lisp"))
 16: (SB-EXT:CALL-WITH-TIMING #<FUNCTION SB-IMPL::PRINT-TIME> #<FUNCTION
(LAMBDA NIL :IN "/mnt/c/d/j.lisp") {532AC28B}>)
 17: (SB-FASL::LOAD-FASL-GROUP #S(SB-FASL::FASL-INPUT :STREAM
#<SB-SYS:FD-STREAM for "file /tmp/slimevhCUGK.fasl" {1014AED913}> :TABLE
#(49 #<PACKAGE "SB-EXT"> SB-EXT:CALL-WITH-TIMING FDEFINITION #<PACKAGE..
 18: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file
/tmp/slimevhCUGK.fasl" {1014AED913}> NIL NIL)
 19: ((FLET SB-FASL::THUNK :IN LOAD))
 20: (SB-FASL::CALL-WITH-LOAD-BINDINGS #<CLOSURE (FLET SB-FASL::THUNK
:IN LOAD) {7F84B6535D2B}> #<SB-SYS:FD-STREAM for "file
/tmp/slimevhCUGK.fasl" {1014AED913}>)
 21: ((FLET SB-FASL::LOAD-STREAM :IN LOAD) #<SB-SYS:FD-STREAM for "file
/tmp/slimevhCUGK.fasl" {1014AED913}> T)
 22: (LOAD #P"/tmp/slimevhCUGK.fasl" :VERBOSE NIL :PRINT NIL
:IF-DOES-NOT-EXIST T :EXTERNAL-FORMAT :DEFAULT)
 23: ((FLET SWANK/BACKEND:CALL-WITH-COMPILATION-HOOKS :IN
"/home/n/quicklisp/dists/quicklisp/software/slime-v2.27/swank/sbcl.lisp")
#<CLOSURE (LAMBDA NIL :IN SWANK/BACKEND:SWANK-COMPILE-STRING) {1014AECF4B..
 24: ((FLET SWANK/BACKEND:SWANK-COMPILE-STRING :IN
"/home/n/quicklisp/dists/quicklisp/software/slime-v2.27/swank/sbcl.lisp")
"(time (april \"B←300⌽A ⋄ 10\")) ..)
 25: ((LAMBDA NIL :IN SWANK:COMPILE-STRING-FOR-EMACS))
 26: ((LAMBDA NIL :IN SWANK::COLLECT-NOTES))
 27: (SWANK::MEASURE-TIME-INTERVAL #<CLOSURE (LAMBDA NIL :IN
SWANK::COLLECT-NOTES) {1013B9E7AB}>)
 28: (SWANK::COLLECT-NOTES #<CLOSURE (LAMBDA NIL :IN
SWANK:COMPILE-STRING-FOR-EMACS) {1013B9E75B}>)
 29: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<CLOSURE (LAMBDA NIL :IN
SWANK:COMPILE-STRING-FOR-EMACS) {1013B9E70B}>)
 30: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:COMPILE-STRING-FOR-EMACS
"(time (april \"B←300⌽A ⋄ 10\")) ..)
 31: (EVAL (SWANK:COMPILE-STRING-FOR-EMACS "(time (april \"BΓåÉ300Γî╜A
Γïä 10\")) ..)
 32: (SWANK:EVAL-FOR-EMACS (SWANK:COMPILE-STRING-FOR-EMACS "(time (april
\"B←300⌽A ⋄ 10\")) ..)
 33: ((LAMBDA NIL :IN SWANK::SPAWN-WORKER-THREAD))
 34: (SWANK/SBCL::CALL-WITH-BREAK-HOOK #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN
SWANK::SPAWN-WORKER-THREAD) {52D30FBB}>)
 35: ((FLET SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK :IN
"/home/n/quicklisp/dists/quicklisp/software/slime-v2.27/swank/sbcl.lisp")
#<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN
SWANK::SPAWN..
 36: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-INPUT* .
#<SWANK/GRAY::SLIME-INPUT-STREAM {1008DE1903}>)) #<FUNCTION (LAMBDA NIL
:IN SWANK::SPAWN-WORKER-THREAD) {52D3122B}>)
 37: ((LAMBDA NIL :IN SWANK::SPAWN-WORKER-THREAD))
 38: ((FLET SB-UNIX::BODY :IN SB-THREAD::NEW-LISP-THREAD-TRAMPOLINE))
 39: ((FLET "WITHOUT-INTERRUPTS-BODY-4" :IN
SB-THREAD::NEW-LISP-THREAD-TRAMPOLINE))
 40: ((FLET SB-THREAD::WITH-MUTEX-THUNK :IN
SB-THREAD::NEW-LISP-THREAD-TRAMPOLINE))
 41: ((FLET "WITHOUT-INTERRUPTS-BODY-1" :IN SB-THREAD::CALL-WITH-MUTEX))
 42: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET
SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::NEW-LISP-THREAD-TRAMPOLINE)
{7F84B6536D7B}> #<SB-THREAD:MUTEX "thread result lock" owner:
#<SB-THREAD:THREAD "wor..
 43: (SB-THREAD::NEW-LISP-THREAD-TRAMPOLINE #<SB-THREAD:THREAD "worker"
RUNNING {1013B5D023}> NIL #<CLOSURE (LAMBDA NIL :IN
SWANK::SPAWN-WORKER-THREAD) {1013B5CFCB}> NIL)
 44: ("foreign function: call_into_lisp")
 45: ("foreign function: new_thread_trampoline")

_______________________________________________
Sbcl-help mailing list
Sbcl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Douglas Katzman via Sbcl-help]

The differences in #+/- win32 call convention are subtle, but enough to cause the compiler to choose different registers.

You can easily see which instruction emitters assert that they work only on RAX by looking for that aver in x86-64/insts.

Unless you can produce a standalone example, it's likely this occurs only as a result of adding in your vops, which probably means it's directly attributable to incorrect register specifications in code you added.

It's unfair to characterize it as a bug in this case, but the message presumes nobody writes asm code.

[Andrew Sengul]

I figured that the "probably a bug in SBCL" messages were written with
the expectation that users weren't writing vops. Are you saying the
error happens in this case because an instruction has been emitted
that's trying to use RCX (as seen in line 0 of the backtrace) but in
fact can only use RAX? In x86-64/insts I find only a few instructions
with accumulator-p avers, none of which I use, there's XCHG and MOVABS.
MUL has an implicit RAX argument, could it be happening because
something is trying to do a MUL instruction with two arguments and the
first isn't RAX? I have MUL and DIV instructions using ECX, I'm not sure
if something involving those would trip the aver.

[Douglas Katzman via Sbcl-help]

Don't use 2-operand MUL and you won't have this problem.

Taking 2 args was a mistake carried over from the 32-bit x86 assembler.

You may find https://www.felixcloutier.com/x86/mul helpful