Foreign library call (INITIALIZE) fails on Windows

[mobius-eng]

Trying (cl-yaml:parse "{ a: 1, b: 2}") on Windows fails with the call to INITIALIZE in cl-libyaml.

libyaml.dll is installed from MINGW64 in "c:\msys64\mingw64\bin" (in PATH) (NB. MINGW64 library is called libyaml-0-2.dll, as on *nix systems, I've just copied it to libyaml.dll)

Lisp: SBCL 1.3.6 (installed from roswell)

[mobius-eng]

Just to add: tested using this C-code just to see if libyaml.dll works:

#include <stdio.h>
#include <yaml.h>

int main(void)
{
  FILE *fh = fopen("base.yaml", "r");
  yaml_parser_t parser;

  /* Initialize parser */
  if(!yaml_parser_initialize(&parser))
    fputs("Failed to initialize parser!\n", stderr);
  if(fh == NULL)
    fputs("Failed to open file!\n", stderr);

  /* Set input file */
  yaml_parser_set_input_file(&parser, fh);

  /* CODE HERE */
  printf("\nOpened and parsed successfully\n");

  /* Cleanup */
  yaml_parser_delete(&parser);
  fclose(fh);
  return 0;
}

[phmarek]

I'm suffering this incompatibility as well.

yaml.h contains lots of int... CFFI says the size of parser-t is 480 bytes, and the DLL clears the same amount of RAM... so it seems to be not as easy.

[phmarek]

I've collected a bit of data...

I run

set PATH=%PATH%;windows-libs\mingw64\bin\
sbcl --script debug-yaml.lisp --noinform --dynamic-space-size 128

with this file:

#-quicklisp                                                                                    
(let ((quicklisp-init #P"i:/quicklisp/setup.lisp"))
  (when (probe-file quicklisp-init)                                                            
    (load quicklisp-init)))                                                                    

(ql:quickload "cl-yaml")

(sb-ext:enable-debugger)
(setf *debugger-hook*
      (lambda (c p)
        (print c *debug-io*)
        (sb-debug:print-backtrace)
        (terpri *debug-io*)
        (force-output *debug-io*)
        (sleep 3600)))

(yaml:parse #P"config/m-i-b-windows.yaml")

and when it crashes

#<SB-WIN32:EXCEPTION {10045BEDE3}>
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1005740A43}>
0: ((LAMBDA (C P) :IN "debug-yaml.lisp") #<SB-WIN32:EXCEPTION {10045BEDE3}> #<unused argument>)
1: (SB-DEBUG::RUN-HOOK *DEBUGGER-HOOK* #<SB-WIN32:EXCEPTION {10045BEDE3}>)
2: (INVOKE-DEBUGGER #<SB-WIN32:EXCEPTION {10045BEDE3}>)
3: (CERROR "Return from the exception handler" SB-WIN32:EXCEPTION :CONTEXT #.(SB-SYS:INT-SAP #X0090D8B0) :RECORD #.(SB-SYS:INT-SAP #X0090E4C0) :CODE 3221226356)
4: (SB-KERNEL:HANDLE-WIN32-EXCEPTION #.(SB-SYS:INT-SAP #X0090D8B0) #.(SB-SYS:INT-SAP #X0090E4C0))
5: ("foreign function: #x42CAF3")
6: ("foreign function: #x404097")
7: (YAML.PARSER::PARSE-YAML #<(SIMPLE-ARRAY CHARACTER (1431)) ...

The exception :CODE is 3221226356 == c0000374 which means heap corruption.

I took a process dump (via taskmgr) and looked at that via windbg.

Here's the disassembly:

00000000`0042cad6 740a            je      sbcl!call_into_lisp+0x42 (00000000`0042cae2)
00000000`0042cad8 7c0b            jl      sbcl!call_into_lisp+0x45 (00000000`0042cae5)
00000000`0042cada 488b7310        mov     rsi,qword ptr [rbx+10h]
00000000`0042cade 488b7b08        mov     rdi,qword ptr [rbx+8]
00000000`0042cae2 488b13          mov     rdx,qword ptr [rbx]
00000000`0042cae5 48d1e1          shl     rcx,1
00000000`0042cae8 4831db          xor     rbx,rbx
00000000`0042caeb 55              push    rbp
00000000`0042caec 55              push    rbp
00000000`0042caed 4889e5          mov     rbp,rsp
00000000`0042caf0 ff50fd          call    qword ptr [rax-3]
00000000`0042caf3 7303            jae     sbcl!call_into_lisp+0x58 (00000000`0042caf8)
00000000`0042caf5 4889dc          mov     rsp,rbx
00000000`0042caf8 415f            pop     r15
00000000`0042cafa 415e            pop     r14
00000000`0042cafc 415d            pop     r13
00000000`0042cafe 415c            pop     r12
00000000`0042cb00 5b              pop     rbx
00000000`0042cb01 4889d0          mov     rax,rdx
00000000`0042cb04 4c89fd          mov     rbp,r15
00000000`0042cb07 415f            pop     r15
00000000`0042cb09 4883c408        add     rsp,8
00000000`0042cb0d c3              ret

00000000`0040406a 440f297df0      movaps  xmmword ptr [rbp-10h],xmm15
00000000`0040406f 4c894530        mov     qword ptr [rbp+30h],r8
00000000`00404073 66480f6ec2      movq    xmm0,rdx
00000000`00404078 4889cf          mov     rdi,rcx
00000000`0040407b ba02000000      mov     edx,2
00000000`00404080 488db550ffffff  lea     rsi,[rbp-0B0h]
00000000`00404087 0f164530        movhps  xmm0,qword ptr [rbp+30h]
00000000`0040408b 0f298550ffffff  movaps  xmmword ptr [rbp-0B0h],xmm0
00000000`00404092 e8098a0200      call    sbcl!call_into_lisp (00000000`0042caa0)
00000000`00404097 90              nop
00000000`00404098 0f28742410      movaps  xmm6,xmmword ptr [rsp+10h]
00000000`0040409d 0f287c2420      movaps  xmm7,xmmword ptr [rsp+20h]
00000000`004040a2 440f284580      movaps  xmm8,xmmword ptr [rbp-80h]
00000000`004040a7 440f284d90      movaps  xmm9,xmmword ptr [rbp-70h]
00000000`004040ac 440f2855a0      movaps  xmm10,xmmword ptr [rbp-60h]
00000000`004040b1 440f285db0      movaps  xmm11,xmmword ptr [rbp-50h]
00000000`004040b6 440f2865c0      movaps  xmm12,xmmword ptr [rbp-40h]

Sadly I've got no idea where to look now.

[simendsjo]

I'm getting issues on windows as well. Tested building libyaml from scratch using the vc toolchain (0.2.4 and master) as well as the mingw precompiled libyaml-0-2.dll.

I see the original issue is from 2016. Is anyone using it on Windows?