sbcl-bugs — New bug reports. Moderated, subscription not required for posting.

Re: [Sbcl-bugs] OR with multiple VALUES

[Stas B. <sta...@gm...>]

Only one value will be returned here, as per the standard.

On Sat, Sep 20, 2025 at 12:45 AM Dave Brown <dav...@ho...> wrote:
>
> SBCL Bug Report
>
> Description: SBCL seems to truncate multiple values to single values when OR expressions contain multiple branches that return VALUES forms.
>
> Example:
>  * (or (values 1 2) (values 3 4))
> 1
>
> Expected: 1, 2 (multiple values preserved)
>
> Running Windows 11, SBCL 2.5.8
>
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

[Sbcl-bugs] OR with multiple VALUES

[Dave B. <dav...@ho...>]

SBCL Bug Report

Description: SBCL seems to truncate multiple values to single values when OR expressions contain multiple branches that return VALUES forms.

Example:
 * (or (values 1 2) (values 3 4))
1

Expected: 1, 2 (multiple values preserved)

Running Windows 11, SBCL 2.5.8

Re: [Sbcl-bugs] [Sbcl-devel] Osicat fails to install with current quicklisp (PR available)

[Josef W. <jw...@ra...>]

Hello,

I have created a pull-request to fix this problem. But there seems to be no
one to review the PR. I can't see who is administering the project?


On Sun, Sep 14, 2025 at 12:01:27AM +0200, Josef Wolf wrote:
> Hello all,
> 
> sorry if this is the wrong list for this question, but the quicklisp list
> seems to have vanished, so I'm askig here.
> 
> I'm trying to install sbcl+quicklisp in a docker container based on alpine-linusx 3.21.3
> 
> When installing osicat, I get this error:
> 
>    /root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c: In function 'strerror_r_cffi_wrap':
>    /root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c:140:10: error: returning 'int' from a function with return type 'char *' makes pointer from integer without a cast [-Wint-conversion]
>      140 |   return strerror_r(errnum, buf, buflen);
>         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    Unhandled UIOP/RUN-PROGRAM:SUBPROCESS-ERROR in thread #<error printing a SB-THREAD:THREAD: #<PRINT-NOT-READABLE {1002B44BC3}>>: Subprocess #<UIOP/LAUNCH-PROGRAM::PROCESS-INFO {1002B1D833}> with command ("cc" "-o" "/root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper-tmpXDD6GKJ.o" "-c" "-g" "-Wall" "-Wundef" "-Wsign-compare" "-Wpointer-arith" "-O3" "-D_LARGEFILE_SOURCE" "-D_LARGEFILE64_SOURCE" "-D_FILE_OFFSET_BITS=64" "-Wunused-parameter" "-fno-omit-frame-pointer" "-momit-leaf-frame-pointer" "-fPIC" "-I/common-lisp/dists/quicklisp/software/cffi-20250622-git/" "/root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c")
>    exited with error code 1
> 
> I suspect, osicat expects the GNU version of strerror_r() but gets the XSI
> variant because no language standard is explicitly specified on the command
> line of the compiler.
> 
> Any ideas?
> 
> PS: Here is the Dockerfile I use to build the container:
> 
> FROM alpine:3.21.3 AS builder
> 
> ARG http_proxy
> ARG https_proxy
> ARG HTTP_PROXY
> ARG HTTPS_PROXY
> ARG version
> 
> RUN apk update \
>  && apk add --no-cache abuild
> 
> # copy quicklisp public gpg keys for signature verification
> COPY pubkeys/ /root/pubkeys
> 
> RUN apk add emacs alpine-sdk sbcl rlwrap gpg gpgv curl
> 
> # Install sbcl from source
> RUN apk add git linux-headers texinfo texlive texlive-dvi texmf-dist
> RUN mkdir /common-lisp
> RUN cd /common-lisp      && git clone https://github.com/sbcl/sbcl.git
> RUN cd /common-lisp/sbcl && git checkout sbcl-2.5.1 && sh make.sh
> RUN cd /common-lisp/sbcl && sh install.sh
> RUN apk del sbcl
> 
> # Download Quicklisp installer
> RUN mkdir ql
> RUN for f in quicklisp.lisp.asc quicklisp.lisp ; do \
>         curl https://beta.quicklisp.org/$f -o ql/$f || exit 1; \
>     done
> 
> RUN cd /root/pubkeys && gpg --yes -o release-key.gpg --dearmor release-key.txt
> RUN gpgv --keyring /root/pubkeys/release-key.gpg ql/quicklisp.lisp.asc ql/quicklisp.lisp
> 
> # Install Quicklisp
> ARG ql_packages="str cl-fad cl-ppcre osicat alexandria split-sequence ironclad cl-base64 plump-sexp lquery cxml clss xpath clingon fiveam mockingbird cl-coveralls ci-utils parachute mockingbird"
> RUN sbcl --noinform --disable-ldb \
>          --lose-on-corruption --end-runtime-options \
>          --disable-debugger \
>          --eval '(load "ql/quicklisp.lisp")' \
>          --eval '(quicklisp-quickstart:install :path "/common-lisp")' \
>          --eval '(setf ql-util::*do-not-prompt* t)' \
>          --eval '(setf *query-io*     *standard-output*)' \
>          --eval '(setf *debug-io*     *standard-output*)' \
>          --eval '(setf *trace-output* *standard-output*)' \
>          --eval '(ql:add-to-init-file)' \
>          --eval '(ql:update-client)' \
>          --eval '(ql:update-dist "quicklisp")' \
>          --eval '(ql:update-all-dists)' \
>          --eval "(dolist (pkg '($ql_packages)) (ql:quickload pkg))" \
>          --eval '(quit)'
>                                                                                                                               
> -- 
> Josef Wolf
> jw...@ra...
> 
> 
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

-- 
Josef Wolf
jw...@ra...

Re: [Sbcl-bugs] [Sbcl-devel] Osicat fails to install with current quicklisp

[Josef W. <jw...@ra...>]

It works fine with alipne-3.20.3 (which comes with gcc-13.2.1) but breaks with
alpine-3.21.0, which comes with gcc-14.2.0-rc4

Thus the problem is probably caused by the switch gcc-13 -> gcc-14

Guess, some kind of -std=XXX option needs to be specified to gcc to get it
complied. Which component is responsible to provide proper compiler options?
Ist it CFFI or something?

On Sun, Sep 14, 2025 at 12:01:27AM +0200, Josef Wolf wrote:
> Hello all,
> 
> sorry if this is the wrong list for this question, but the quicklisp list
> seems to have vanished, so I'm askig here.
> 
> I'm trying to install sbcl+quicklisp in a docker container based on alpine-linusx 3.21.3
> 
> When installing osicat, I get this error:
> 
>    /root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c: In function 'strerror_r_cffi_wrap':
>    /root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c:140:10: error: returning 'int' from a function with return type 'char *' makes pointer from integer without a cast [-Wint-conversion]
>      140 |   return strerror_r(errnum, buf, buflen);
>         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    Unhandled UIOP/RUN-PROGRAM:SUBPROCESS-ERROR in thread #<error printing a SB-THREAD:THREAD: #<PRINT-NOT-READABLE {1002B44BC3}>>: Subprocess #<UIOP/LAUNCH-PROGRAM::PROCESS-INFO {1002B1D833}> with command ("cc" "-o" "/root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper-tmpXDD6GKJ.o" "-c" "-g" "-Wall" "-Wundef" "-Wsign-compare" "-Wpointer-arith" "-O3" "-D_LARGEFILE_SOURCE" "-D_LARGEFILE64_SOURCE" "-D_FILE_OFFSET_BITS=64" "-Wunused-parameter" "-fno-omit-frame-pointer" "-momit-leaf-frame-pointer" "-fPIC" "-I/common-lisp/dists/quicklisp/software/cffi-20250622-git/" "/root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c")
>    exited with error code 1
> 
> I suspect, osicat expects the GNU version of strerror_r() but gets the XSI
> variant because no language standard is explicitly specified on the command
> line of the compiler.
> 
> Any ideas?
> 
> PS: Here is the Dockerfile I use to build the container:
> 
> FROM alpine:3.21.3 AS builder
> 
> ARG http_proxy
> ARG https_proxy
> ARG HTTP_PROXY
> ARG HTTPS_PROXY
> ARG version
> 
> RUN apk update \
>  && apk add --no-cache abuild
> 
> # copy quicklisp public gpg keys for signature verification
> COPY pubkeys/ /root/pubkeys
> 
> RUN apk add emacs alpine-sdk sbcl rlwrap gpg gpgv curl
> 
> # Install sbcl from source
> RUN apk add git linux-headers texinfo texlive texlive-dvi texmf-dist
> RUN mkdir /common-lisp
> RUN cd /common-lisp      && git clone https://github.com/sbcl/sbcl.git
> RUN cd /common-lisp/sbcl && git checkout sbcl-2.5.1 && sh make.sh
> RUN cd /common-lisp/sbcl && sh install.sh
> RUN apk del sbcl
> 
> # Download Quicklisp installer
> RUN mkdir ql
> RUN for f in quicklisp.lisp.asc quicklisp.lisp ; do \
>         curl https://beta.quicklisp.org/$f -o ql/$f || exit 1; \
>     done
> 
> RUN cd /root/pubkeys && gpg --yes -o release-key.gpg --dearmor release-key.txt
> RUN gpgv --keyring /root/pubkeys/release-key.gpg ql/quicklisp.lisp.asc ql/quicklisp.lisp
> 
> # Install Quicklisp
> ARG ql_packages="str cl-fad cl-ppcre osicat alexandria split-sequence ironclad cl-base64 plump-sexp lquery cxml clss xpath clingon fiveam mockingbird cl-coveralls ci-utils parachute mockingbird"
> RUN sbcl --noinform --disable-ldb \
>          --lose-on-corruption --end-runtime-options \
>          --disable-debugger \
>          --eval '(load "ql/quicklisp.lisp")' \
>          --eval '(quicklisp-quickstart:install :path "/common-lisp")' \
>          --eval '(setf ql-util::*do-not-prompt* t)' \
>          --eval '(setf *query-io*     *standard-output*)' \
>          --eval '(setf *debug-io*     *standard-output*)' \
>          --eval '(setf *trace-output* *standard-output*)' \
>          --eval '(ql:add-to-init-file)' \
>          --eval '(ql:update-client)' \
>          --eval '(ql:update-dist "quicklisp")' \
>          --eval '(ql:update-all-dists)' \
>          --eval "(dolist (pkg '($ql_packages)) (ql:quickload pkg))" \
>          --eval '(quit)'
>                                                                                                                               
> -- 
> Josef Wolf
> jw...@ra...
> 
> 
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

-- 
Josef Wolf
jw...@ra...

[Sbcl-bugs] Osicat fails to install with current quicklisp

[Josef W. <jw...@ra...>]

Hello all,

sorry if this is the wrong list for this question, but the quicklisp list
seems to have vanished, so I'm askig here.

I'm trying to install sbcl+quicklisp in a docker container based on alpine-linusx 3.21.3

When installing osicat, I get this error:

   /root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c: In function 'strerror_r_cffi_wrap':
   /root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c:140:10: error: returning 'int' from a function with return type 'char *' makes pointer from integer without a cast [-Wint-conversion]
     140 |   return strerror_r(errnum, buf, buflen);
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Unhandled UIOP/RUN-PROGRAM:SUBPROCESS-ERROR in thread #<error printing a SB-THREAD:THREAD: #<PRINT-NOT-READABLE {1002B44BC3}>>: Subprocess #<UIOP/LAUNCH-PROGRAM::PROCESS-INFO {1002B1D833}> with command ("cc" "-o" "/root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper-tmpXDD6GKJ.o" "-c" "-g" "-Wall" "-Wundef" "-Wsign-compare" "-Wpointer-arith" "-O3" "-D_LARGEFILE_SOURCE" "-D_LARGEFILE64_SOURCE" "-D_FILE_OFFSET_BITS=64" "-Wunused-parameter" "-fno-omit-frame-pointer" "-momit-leaf-frame-pointer" "-fPIC" "-I/common-lisp/dists/quicklisp/software/cffi-20250622-git/" "/root/.cache/common-lisp/sbcl-2.5.8-linux-x64/common-lisp/dists/quicklisp/software/osicat-20250622-git/posix/wrappers__wrapper.c")
   exited with error code 1

I suspect, osicat expects the GNU version of strerror_r() but gets the XSI
variant because no language standard is explicitly specified on the command
line of the compiler.

Any ideas?

PS: Here is the Dockerfile I use to build the container:

FROM alpine:3.21.3 AS builder

ARG http_proxy
ARG https_proxy
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG version

RUN apk update \
 && apk add --no-cache abuild

# copy quicklisp public gpg keys for signature verification
COPY pubkeys/ /root/pubkeys

RUN apk add emacs alpine-sdk sbcl rlwrap gpg gpgv curl

# Install sbcl from source
RUN apk add git linux-headers texinfo texlive texlive-dvi texmf-dist
RUN mkdir /common-lisp
RUN cd /common-lisp      && git clone https://github.com/sbcl/sbcl.git
RUN cd /common-lisp/sbcl && git checkout sbcl-2.5.1 && sh make.sh
RUN cd /common-lisp/sbcl && sh install.sh
RUN apk del sbcl

# Download Quicklisp installer
RUN mkdir ql
RUN for f in quicklisp.lisp.asc quicklisp.lisp ; do \
        curl https://beta.quicklisp.org/$f -o ql/$f || exit 1; \
    done

RUN cd /root/pubkeys && gpg --yes -o release-key.gpg --dearmor release-key.txt
RUN gpgv --keyring /root/pubkeys/release-key.gpg ql/quicklisp.lisp.asc ql/quicklisp.lisp

# Install Quicklisp
ARG ql_packages="str cl-fad cl-ppcre osicat alexandria split-sequence ironclad cl-base64 plump-sexp lquery cxml clss xpath clingon fiveam mockingbird cl-coveralls ci-utils parachute mockingbird"
RUN sbcl --noinform --disable-ldb \
         --lose-on-corruption --end-runtime-options \
         --disable-debugger \
         --eval '(load "ql/quicklisp.lisp")' \
         --eval '(quicklisp-quickstart:install :path "/common-lisp")' \
         --eval '(setf ql-util::*do-not-prompt* t)' \
         --eval '(setf *query-io*     *standard-output*)' \
         --eval '(setf *debug-io*     *standard-output*)' \
         --eval '(setf *trace-output* *standard-output*)' \
         --eval '(ql:add-to-init-file)' \
         --eval '(ql:update-client)' \
         --eval '(ql:update-dist "quicklisp")' \
         --eval '(ql:update-all-dists)' \
         --eval "(dolist (pkg '($ql_packages)) (ql:quickload pkg))" \
         --eval '(quit)'
                                                                                                                              
-- 
Josef Wolf
jw...@ra...

Re: [Sbcl-bugs] Help debugging CFFI

[Stas B. <sta...@gm...>]

It all depends on which side of save-lisp-and-die this is done.

On Fri, Sep 12, 2025 at 2:41 PM André A. Gomes <and...@gm...> wrote:
>
> Stas Boukarev <sta...@gm...> writes:
>
> > Are you saving pointers to foreign memory into a core? Initializing
> > things before saving and not after starting?
>
> Hi Stas,
>
> Thank you for pointing me in the right direction.
>
> I took a deeper look at the CFFI dependencies[1] and found the snippet
> below.  Does it look fishy?
>
> --8<---------------cut here---------------start------------->8---
> ;;; ----------------------------------------------------------------------------
> ;;; GAsyncReadyCallback
> ;;; ----------------------------------------------------------------------------
>
> ;; TODO: We free the allocated pointer in an UNWIND-PROTECT macro. Is this safe?
>
> (cffi:defcallback async-ready-callback :void
>     ((source gobject:object)
>      (result (gobject:object async-result))
>      (data :pointer))
>   (let ((func (glib:get-stable-pointer-value data)))
>     (unwind-protect
>       (funcall func source result))
>       (glib:free-stable-pointer data)))
> --8<---------------cut here---------------end--------------->8---
>
>
> Footnotes:
> [1]  https://github.com/crategus/cl-cffi-glib/
>
>
> --
> André A. Gomes
> "You cannot even find the ruins..."

Re: [Sbcl-bugs] Help debugging CFFI

[André A. G. <and...@gm...>]

Stas Boukarev <sta...@gm...> writes:

> Are you saving pointers to foreign memory into a core? Initializing
> things before saving and not after starting?

Hi Stas,

Thank you for pointing me in the right direction.

I took a deeper look at the CFFI dependencies[1] and found the snippet
below.  Does it look fishy?  

--8<---------------cut here---------------start------------->8---
;;; ----------------------------------------------------------------------------
;;; GAsyncReadyCallback
;;; ----------------------------------------------------------------------------

;; TODO: We free the allocated pointer in an UNWIND-PROTECT macro. Is this safe?

(cffi:defcallback async-ready-callback :void
    ((source gobject:object)
     (result (gobject:object async-result))
     (data :pointer))
  (let ((func (glib:get-stable-pointer-value data)))
    (unwind-protect
      (funcall func source result))
      (glib:free-stable-pointer data)))
--8<---------------cut here---------------end--------------->8---


Footnotes:
[1]  https://github.com/crategus/cl-cffi-glib/


-- 
André A. Gomes
"You cannot even find the ruins..."

Re: [Sbcl-bugs] Help debugging CFFI

[Stas B. <sta...@gm...>]

Are you saving pointers to foreign memory into a core? Initializing
things before saving and not after starting?

On Thu, Sep 11, 2025 at 2:42 PM André A. Gomes <and...@gm...> wrote:
>
> Hello,
>
> I wrote bindings to WebKitGTK with CFFI.  When I compile a simple
> program to a binary using those bindings (via asdf:make), it crashes
> with SIGABRT (see log below).
>
> When I run the same code from the SLY REPL, it doesn't crash...  How can
> I make sense of it?
>
> Additionally, when I compile the same exact program with CCL, it also
> doesn't crash.  This seems to suggest that there is an issue with CFFI
> (the compatibility layer) or with SBCL's interface to C programs.  How
> can I debug this?  I've tried strace but it didn't help me much.  Any
> pointer would be greatly appreciated.  Thank you.
>
> --8<---------------cut here---------------start------------->8---
> fatal error encountered in SBCL pid 12170 tid 12170:
> SIGABRT received.
>
>    0: fp=0x790c69aef010 pc=0x790c69ea49bc Foreign function pthread_kill
>    1: fp=0x790c69aef030 pc=0x790c69e4579e Foreign function gsignal
>    2: fp=0x790c69aef100 pc=0x790c69e288cd Foreign function abort
>    3: fp=0x790c69aef110 pc=0x790c5fd60cbd Foreign function (null)
>    4: fp=0x790c69aef190 pc=0x790c60fe97bf Foreign function (null)
>    5: fp=0x790c69aef2b0 pc=0x790c60fe447d Foreign function (null)
>    6: fp=0x790c69aef2e0 pc=0x790c60fe63e4 Foreign function (null)
>    7: fp=0x790c69aef300 pc=0x790c5fe6df99 Foreign function JSContextGroupCreate
>    8: fp=0x790c69aef320 pc=0x790c5fe1b520 Foreign function (null)
>    9: fp=0x790c69aef370 pc=0x790c5fdeb597 Foreign function (null)
>   10: fp=0x790c69aef3b0 pc=0x790c5fdeb318 Foreign function (null)
>   11: fp=0x790c69aef450 pc=0x790c696a0a28 Foreign function (null)
>   12: fp=0x790c69aef4c0 pc=0x790c6967c683 Foreign function g_object_new_with_properties
>   13: fp=0x790c69aef5a0 pc=0x790c6967d7f1 Foreign function g_object_new
>   14: fp=0x790c69aef5c0 pc=0x790c0b6aafc9 Foreign function (null)
>   15: fp=0x790c69aef5f0 pc=0x790c0b6ab02b Foreign function (null)
>   16: fp=0x790c69aef660 pc=0x790c0b701dc8 Foreign function (null)
>   17: fp=0x790c69aef6c0 pc=0x790c0b64363f Foreign function (null)
>   18: fp=0x790c69aef750 pc=0x790c0b642d9a Foreign function (null)
>   19: fp=0x790c69aef770 pc=0x790c0b58239f Foreign function (null)
>   20: fp=0x790c69aef7b0 pc=0x790c0b5389ac Foreign function (null)
>   21: fp=0x790c69aef7e0 pc=0x790c0b538b56 Foreign function (null)
>   22: fp=0x790c69aef860 pc=0x790c0b539030 Foreign function (null)
>   23: fp=0x790c69aef8e0 pc=0x790c6145ebf9 Foreign function (null)
>   24: fp=0x790c69aef8f0 pc=0x790c6151760d Foreign function (null)
>   25: fp=0x790c69aef920 pc=0x790c61516861 Foreign function (null)
>   26: fp=0x790c69aef9d0 pc=0x790c697e5de2 Foreign function (null)
>   27: fp=0x790c69aefa70 pc=0x790c698571f8 Foreign function (null)
>   28: fp=0x790c69aefa90 pc=0x790c697e6223 Foreign function g_main_context_iteration
>   29: fp=0x790c69aefaf0 pc=0x790c69556c3d Foreign function g_application_run
>   30: fp=0x790c69aefbb0 pc=0xb800242b2f GIO::%APPLICATION-RUN
>   31: fp=0x790c69aefd18 pc=0xb800609054 CL-BC-BROWSER::ENTRY-POINT
>   32: fp=0x790c69aefda0 pc=0xb80108230d (LAMBDA () :IN UIOP/IMAGE::RESTORE-IMAGE)
>   33: fp=0x790c69aefdd8 pc=0xb80108150e UIOP/IMAGE::CALL-WITH-FATAL-CONDITION-HANDLER
>   34: fp=0x790c69aefe70 pc=0xb801050f7b (FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP)
>   35: fp=0x790c69aeff30 pc=0xb801050d86 (FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP)
>   36: fp=0x790c69aeffc8 pc=0xb801050bb4 SB-IMPL::%START-LISP
> --8<---------------cut here---------------end--------------->8---
>
> --
> André A. Gomes
> "You cannot even find the ruins..."
>
>
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

[Sbcl-bugs] Help debugging CFFI

[André A. G. <and...@gm...>]

Hello,

I wrote bindings to WebKitGTK with CFFI.  When I compile a simple
program to a binary using those bindings (via asdf:make), it crashes
with SIGABRT (see log below).

When I run the same code from the SLY REPL, it doesn't crash...  How can
I make sense of it?

Additionally, when I compile the same exact program with CCL, it also
doesn't crash.  This seems to suggest that there is an issue with CFFI
(the compatibility layer) or with SBCL's interface to C programs.  How
can I debug this?  I've tried strace but it didn't help me much.  Any
pointer would be greatly appreciated.  Thank you.

--8<---------------cut here---------------start------------->8---
fatal error encountered in SBCL pid 12170 tid 12170:
SIGABRT received.

   0: fp=0x790c69aef010 pc=0x790c69ea49bc Foreign function pthread_kill
   1: fp=0x790c69aef030 pc=0x790c69e4579e Foreign function gsignal
   2: fp=0x790c69aef100 pc=0x790c69e288cd Foreign function abort
   3: fp=0x790c69aef110 pc=0x790c5fd60cbd Foreign function (null)
   4: fp=0x790c69aef190 pc=0x790c60fe97bf Foreign function (null)
   5: fp=0x790c69aef2b0 pc=0x790c60fe447d Foreign function (null)
   6: fp=0x790c69aef2e0 pc=0x790c60fe63e4 Foreign function (null)
   7: fp=0x790c69aef300 pc=0x790c5fe6df99 Foreign function JSContextGroupCreate
   8: fp=0x790c69aef320 pc=0x790c5fe1b520 Foreign function (null)
   9: fp=0x790c69aef370 pc=0x790c5fdeb597 Foreign function (null)
  10: fp=0x790c69aef3b0 pc=0x790c5fdeb318 Foreign function (null)
  11: fp=0x790c69aef450 pc=0x790c696a0a28 Foreign function (null)
  12: fp=0x790c69aef4c0 pc=0x790c6967c683 Foreign function g_object_new_with_properties
  13: fp=0x790c69aef5a0 pc=0x790c6967d7f1 Foreign function g_object_new
  14: fp=0x790c69aef5c0 pc=0x790c0b6aafc9 Foreign function (null)
  15: fp=0x790c69aef5f0 pc=0x790c0b6ab02b Foreign function (null)
  16: fp=0x790c69aef660 pc=0x790c0b701dc8 Foreign function (null)
  17: fp=0x790c69aef6c0 pc=0x790c0b64363f Foreign function (null)
  18: fp=0x790c69aef750 pc=0x790c0b642d9a Foreign function (null)
  19: fp=0x790c69aef770 pc=0x790c0b58239f Foreign function (null)
  20: fp=0x790c69aef7b0 pc=0x790c0b5389ac Foreign function (null)
  21: fp=0x790c69aef7e0 pc=0x790c0b538b56 Foreign function (null)
  22: fp=0x790c69aef860 pc=0x790c0b539030 Foreign function (null)
  23: fp=0x790c69aef8e0 pc=0x790c6145ebf9 Foreign function (null)
  24: fp=0x790c69aef8f0 pc=0x790c6151760d Foreign function (null)
  25: fp=0x790c69aef920 pc=0x790c61516861 Foreign function (null)
  26: fp=0x790c69aef9d0 pc=0x790c697e5de2 Foreign function (null)
  27: fp=0x790c69aefa70 pc=0x790c698571f8 Foreign function (null)
  28: fp=0x790c69aefa90 pc=0x790c697e6223 Foreign function g_main_context_iteration
  29: fp=0x790c69aefaf0 pc=0x790c69556c3d Foreign function g_application_run
  30: fp=0x790c69aefbb0 pc=0xb800242b2f GIO::%APPLICATION-RUN
  31: fp=0x790c69aefd18 pc=0xb800609054 CL-BC-BROWSER::ENTRY-POINT
  32: fp=0x790c69aefda0 pc=0xb80108230d (LAMBDA () :IN UIOP/IMAGE::RESTORE-IMAGE)
  33: fp=0x790c69aefdd8 pc=0xb80108150e UIOP/IMAGE::CALL-WITH-FATAL-CONDITION-HANDLER
  34: fp=0x790c69aefe70 pc=0xb801050f7b (FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP)
  35: fp=0x790c69aeff30 pc=0xb801050d86 (FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP)
  36: fp=0x790c69aeffc8 pc=0xb801050bb4 SB-IMPL::%START-LISP
--8<---------------cut here---------------end--------------->8---

-- 
André A. Gomes
"You cannot even find the ruins..."

Re: [Sbcl-bugs] Responsible Vulnerability Disclosure

[Christophe R. <cs...@ca...>]

Hello,

I have not confirmed this, but I believe that you can report bugs to our
bug tracker on launchpad at <https://bugs.launchpad.net/sbcl>, and by
choosing the "Private Security" option at the bottom of the bug
reporting page (the prompt is "This bug contains information that is:"),
I believe that means that the visibility of the bug report will be
restricted to the 15 members of the "SBCL Hackers" group.

The above paragraph is how I expect things to work, based on the
launchpad tool's documentation.  The launchpad instance is Ubuntu's own;
if you have any prior experience with using launchpad, you might be in a
better position to confirm or deny that this is in fact how it works in
practice.

Thanks,

Christophe

cv...@cy... via Sbcl-bugs <sbc...@li...> writes:

> Hello SBCL bugs mailing list members,
>
> INCD is a CNA for the MITRE CVE program.
>
> We would like to report a security vulnerability in SBCL.
>
> What email address may we use?
>
> Regards, 
> * cv...@cy...   
>  
> Israel National Cyber Directorate | Active Cyber Defense Center 

[Sbcl-bugs] Type checking bug

[André A. G. <and...@gm...>]

Hello,

Take the snippet below:

--8<---------------cut here---------------start------------->8---
(defun predicate (string)
  (and (char=  #\- (char string 0))
       (char/= #\- (char string 1))))

(deftype short-flag ()
  '(and (string 2) (satisfies predicate)))

(typep "-" 'short-flag)
--8<---------------cut here---------------end--------------->8---

Since "-" is of size 1, then the type specifier should short circuit
before evaluating the form (satisfied predicate).  However, SBCL raises
the condition below:

--8<---------------cut here---------------start------------->8---
Invalid index 1 for (SIMPLE-ARRAY CHARACTER (1)), should be a
non-negative integer below 1.
   [Condition of type SB-INT:INVALID-ARRAY-INDEX-ERROR]
--8<---------------cut here---------------end--------------->8---


Note that CCL returns NIL, as expected.

Thank you.


-- 
André A. Gomes
"You cannot even find the ruins..."

[Sbcl-bugs] Responsible Vulnerability Disclosure

[דיווחי פ. <cv...@cy...>]

Hello SBCL bugs mailing list members,
INCD is a CNA for the MITRE CVE program.
We would like to report a security vulnerability in SBCL.
What email address may we use?

Regards,


[cid:image001.gif@01DC1516.905D7520]


cv...@cy...<mailto:cv...@cy...>


Israel National Cyber Directorate | Active Cyber Defense Center


[cid:image002.png@01DC1516.905D7520]


[cid:image003.gif@01DC1516.905D7520]<https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/www.linkedin.com/company/ncsa-israel-**I-**M-**I-**K__;15TXqNep15XXqteU15zXkNeV157Xmdeq15zXlNeS16DXqteU16HXmdeZ15HXqA!!Pe07N362zA!ngvnyPokhLCnrtySbyPh0WMIexEsXMqufoNmnl04I-PEySfD1tvhcm4t7RobjygN1qy47zYC$___.YXAxZTp2YW50aXZhOmE6bzo4OTE2ZDI4NTZhYjRlODBjYWU1YzJhYTg0NTIxMThiOTo2OjlmNGQ6MGI0OWE1MjlkNWRhODcyOTM2NDczZTE1NTA1NTcwMDllMzhlNmNmMWI2NjBkNWIyYzk1MmJmYWZlOGY1NGZhMjpoOlQ>


[cid:image004.gif@01DC1516.905D7520]<https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/twitter.com/israel_cyber__;!!Pe07N362zA!ngvnyPokhLCnrtySbyPh0WMIexEsXMqufoNmnl04I-PEySfD1tvhcm4t7RobjygN1hksxK91$___.YXAxZTp2YW50aXZhOmE6bzo4OTE2ZDI4NTZhYjRlODBjYWU1YzJhYTg0NTIxMThiOTo2OjJlNjU6MGM4OTY3Mjg2YzU0NjdlMGZhNDVlZTMyN2YwNGQxOWM1YjMxNTJlMzk4MTlhYTM4YjgzYzA0YzMwMTMwMDE3MzpoOlQ>


[cid:image005.gif@01DC1516.905D7520]<https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/www.youtube.com/channel/UCHWw5LlRlRSWVxosc2N-ldg__;!!Pe07N362zA!ngvnyPokhLCnrtySbyPh0WMIexEsXMqufoNmnl04I-PEySfD1tvhcm4t7RobjygN1nG9kh99$___.YXAxZTp2YW50aXZhOmE6bzo4OTE2ZDI4NTZhYjRlODBjYWU1YzJhYTg0NTIxMThiOTo2OmNlYmY6Y2JiZTRhN2I1NTA3YzIxMmIwNGI5YzA4ZWE2MDRkNTVlYTg1YjExZmFjYzdkY2ZjNzE2ZDBiMzQwNGFhMjkzNzpoOlQ>


[cid:image006.png@01DC1516.905D7520]<https://url.avanan.click/v2/___https:/urldefense.com/v3/__https:/www.gov.il/en/departments/israel_national_cyber_directorate__;!!Pe07N362zA!ngvnyPokhLCnrtySbyPh0WMIexEsXMqufoNmnl04I-PEySfD1tvhcm4t7RobjygN1rOERzIP$___.YXAxZTp2YW50aXZhOmE6bzo4OTE2ZDI4NTZhYjRlODBjYWU1YzJhYTg0NTIxMThiOTo2OjZiMmM6NTllYTY0YTg4Y2IwODE4N2YzMmViMzA1NGExZGFhZjFjMzk5ZGNhMDBiMTIwZjc1YWMwNTAzMmNjMWEwMjM3ZjpoOlQ>

Re: [Sbcl-bugs] Reentrancy of file descriptor I/O handlers

[Stas B. <sta...@gm...>]

Actually, I've just realized that *descriptor-handlers* is already
thread-local, oh well...

On Sat, Aug 9, 2025 at 2:52 AM Stas Boukarev <sta...@gm...> wrote:
>
> I applied a modified patch, making it thread-safe. Thanks.
>
> On Wed, Jul 30, 2025 at 10:16 PM Dmytro Statyvka <dst...@gm...> wrote:
> >
> > Good day SBCL developers,
> >
> > So, what do you think about this problem? Any concerns? If you have
> > better ideas regarding ways to fix this, please let me know
> >
> > --
> > Best wishes,
> > Dmytro
> >
> >
> > _______________________________________________
> > Sbcl-bugs mailing list
> > Sbc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

Re: [Sbcl-bugs] Reentrancy of file descriptor I/O handlers

[Stas B. <sta...@gm...>]

I applied a modified patch, making it thread-safe. Thanks.

On Wed, Jul 30, 2025 at 10:16 PM Dmytro Statyvka <dst...@gm...> wrote:
>
> Good day SBCL developers,
>
> So, what do you think about this problem? Any concerns? If you have
> better ideas regarding ways to fix this, please let me know
>
> --
> Best wishes,
> Dmytro
>
>
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

Re: [Sbcl-bugs] Reentrancy of file descriptor I/O handlers

[Dmytro S. <dst...@gm...>]

Good day SBCL developers,

So, what do you think about this problem? Any concerns? If you have
better ideas regarding ways to fix this, please let me know

--
Best wishes,
Dmytro

Re: [Sbcl-bugs] possible sxhash bug

[Stas B. <sta...@gm...>]

sort doesn't use sxhash.

On Mon, Jul 21, 2025 at 5:20 PM Dave Brown <dav...@ho...> wrote:
>
> Hi -- I've been experiencing intermittent, but repeatable, crashes when running my search algorithm (:wouldwork) that I think are related to sorting an alist (produced by alexandria from a fixnum hash table).  When I switch from using sort (which I understand uses sxhash) to using merge-sort-list (by Paul Khuong?) the error seems to go away,  but it seems to double the compute time.  Note that the resultant alists are fairly small < 10 items. Here are some basic details & thanks for any insights:
>
> Message:
> CORRUPTION WARNING in SBCL pid 226247400: Memory fault at 0000000006ae9dff (pc=00000010006a16a0 [code 00000010006a1250+0x450 ID 0x43d0], fp=00000000005fee48, sp=00000000005fee10)7400 The integrity of this image is possibly compromised. Continuing with fingers crossed. debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD tid=7400 "main thread" RUNNING {1102A28093}>: Unhandled memory fault at #x6AE9DFF. Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((LABELS SB-IMPL::SXHASH-RECURSE :IN SB-IMPL::PERHAPS-TRUNCATED-EQUAL-HASH) #<unavailable argument> #<unavailable argument>) 0] down ((LABELS SB-IMPL::SXHASH-RECURSE :IN SB-IMPL::PERHAPS-TRUNCATED-EQUAL-HASH) ((112107125 . T) (112109125 . T) (118108125 . T) (119109125 . T)) 17)
>
> Possible source:
> (defun idb-to-sorted-alist (idb-hash-table)
>   "Converts an IDB hash table to a sorted alist using Alexandria."
>   (sort (alexandria:hash-table-alist idb-hash-table)
>         #'< :key #'car))  ; Sort by fixnum keys
>
> OS:
> Windows 11 Pro, ver 23H2, build 22631.5624
>
> CPU:
> Intel(R) Core(TM) i9-14900K   3.20 GHz
>
> Memory:
> Corsair, 32 GB (2x16), DDR5-4800
>
> SBCL:
> C:\Windows\System32>sbcl --dynamic-space-size 28000
> This is SBCL 2.5.6, an implementation of ANSI Common Lisp.
>
>
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

[Sbcl-bugs] possible sxhash bug

[Dave B. <dav...@ho...>]

Hi -- I've been experiencing intermittent, but repeatable, crashes when running my search algorithm (:wouldwork) that I think are related to sorting an alist (produced by alexandria from a fixnum hash table).  When I switch from using sort (which I understand uses sxhash) to using merge-sort-list (by Paul Khuong?) the error seems to go away,  but it seems to double the compute time.  Note that the resultant alists are fairly small < 10 items. Here are some basic details & thanks for any insights:

Message:
CORRUPTION WARNING in SBCL pid 226247400: Memory fault at 0000000006ae9dff (pc=00000010006a16a0 [code 00000010006a1250+0x450 ID 0x43d0], fp=00000000005fee48, sp=00000000005fee10)7400 The integrity of this image is possibly compromised. Continuing with fingers crossed. debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD tid=7400 "main thread" RUNNING {1102A28093}>: Unhandled memory fault at #x6AE9DFF. Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((LABELS SB-IMPL::SXHASH-RECURSE :IN SB-IMPL::PERHAPS-TRUNCATED-EQUAL-HASH) #<unavailable argument> #<unavailable argument>) 0] down ((LABELS SB-IMPL::SXHASH-RECURSE :IN SB-IMPL::PERHAPS-TRUNCATED-EQUAL-HASH) ((112107125 . T) (112109125 . T) (118108125 . T) (119109125 . T)) 17)

Possible source:
(defun idb-to-sorted-alist (idb-hash-table)
  "Converts an IDB hash table to a sorted alist using Alexandria."
  (sort (alexandria:hash-table-alist idb-hash-table)
        #'< :key #'car))  ; Sort by fixnum keys

OS:
Windows 11 Pro, ver 23H2, build 22631.5624

CPU:
Intel(R) Core(TM) i9-14900K   3.20 GHz

Memory:
Corsair, 32 GB (2x16), DDR5-4800

SBCL:
C:\Windows\System32>sbcl --dynamic-space-size 28000
This is SBCL 2.5.6, an implementation of ANSI Common Lisp.

Re: [Sbcl-bugs] Recursive `#.` forms that mismatch a structure slot type can cause infinite recursion in reading

[Stas B. <sta...@gm...>]

Fixed. Thanks.

On Sat, Jul 12, 2025 at 5:31 PM Bohong Huang via Sbcl-bugs
<sbc...@li...> wrote:
>
> Hello SBCL developers,
>
> The following code:
>
>
>     (defstruct a
>       (a nil :type (or a null)))
>
>     (defun recursive-a ()
>       (let ((a (make-a)))
>         (setf (a-a a) a)))
>
>     (read-from-string "#S(A :A (#.(RECURSIVE-A)))")
>
>
> can exhaust the control stack during execution:
>
>
>     Control stack exhausted (no more space for function call frames).
>     This is probably due to heavily nested or infinitely recursive function
>     calls, or a tail call that SBCL cannot or has not optimized away.
>
>     PROCEED WITH CAUTION.
>        [Condition of type SB-KERNEL::CONTROL-STACK-EXHAUSTED]
>
>     Restarts:
>      0: [RETRY] Retry SLY interactive evaluation request.
>      1: [*ABORT] Return to SLY's top level.
>      2: [ABORT] abort thread (#<THREAD tid=5613 "slynk-worker" RUNNING {1201E9DC13}>)
>
>     Backtrace:
>      0: (SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
>      1: ("foreign function: call_into_lisp_")
>      2: ("foreign function: post_signal_tramp")
>      3: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
>      4: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
>      5: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106A3017B}>)
>      6: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
>      7: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
>      8: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106A3030B}>)
>      9: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
>     10: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
>     11: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106A3049B}>)
>     12: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
>
>     ...
>
>     15134: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106C1C92B}>)
>     15135: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
>     15136: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
>     15137: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) (#1=#S(A :A #1#)))
>     15138: (SB-IMPL::SHARP-EQUAL-VISIT (#1=#S(A :A #1#)) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106C1CB3B}..
>     15139: (SB-IMPL::CONTAINS-MARKER (#1=#S(A :A #1#)))
>     15140: ((LAMBDA (SB-IMPL::C) :IN SB-IMPL::SHARP-S) #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
>     15141: (SB-KERNEL::%SIGNAL #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
>     15142: (ERROR #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
>     15143: (SB-KERNEL:WITH-SIMPLE-CONDITION-RESTARTS ERROR NIL #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
>     15144: ((LABELS SB-KERNEL::TRY :IN SB-KERNEL::RESTART-TYPE-ERROR) #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
>     15145: (SB-KERNEL::RESTART-TYPE-ERROR (OR A NULL) #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))> -60)
>     15146: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #X7F4106C1D040) #<unused argument>)
>     15147: ("foreign function: call_into_lisp_")
>     15148: ("foreign function: funcall2")
>     15149: ("foreign function: interrupt_internal_error")
>     15150: ("foreign function: #x55F1FE926B41")
>     15151: (MAKE-A :A (#1=#S(A :A #1#)))
>     15152: (SB-IMPL::SHARP-S #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> #\S NIL)
>     15153: (SB-IMPL::READ-MAYBE-NOTHING #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> #\#)
>     15154: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> T (NIL) T)
>     15155: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> T (NIL) NIL)
>     15156: (READ #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> T NIL NIL)
>     15157: (SB-IMPL::%READ-FROM-STRING/SAFE "#S(A :A (#.(RECURSIVE-A)))" T NIL 0 NIL NIL)
>     15158: (SB-INT:SIMPLE-EVAL-IN-LEXENV (READ-FROM-STRING "#S(A :A (#.(RECURSIVE-A)))") #<NULL-LEXENV>)
>     15159: (EVAL (READ-FROM-STRING "#S(A :A (#.(RECURSIVE-A)))"))
>
>
> This issue appears to be an issue only in recent versions of SBCL.
> Thank you in advance for taking the time to look into this issue.
>
>
> Best regards,
>
> Bohong Huang
>
>
>
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

Re: [Sbcl-bugs] SB-KERNEL:%MAKE-DOUBLE-FLOAT undefined in SCALE-FLOAT / space 0

[Stas B. <sta...@gm...>]

Fixed. Thanks.

On Wed, Jul 16, 2025 at 1:46 PM Eric Marsden
<eri...@ri...> wrote:
>
> Hi,
>
> This is from random-integer testing on AMD64.
>
> * (lisp-implementation-version)
> "2.5.6.62-95edde758"
> * (defun baz (a) (declare (optimize (space 0)) (type (member 684016 21) a)) (scale-float 1d0 a))
> ; in: DEFUN BAZ
> ;     (SCALE-FLOAT 1.0d0 A)
> ;
> ; caught STYLE-WARNING:
> ;   Lisp error during constant folding:
> ;   The function SB-KERNEL:%MAKE-DOUBLE-FLOAT is undefined.
> ;
> ; compilation unit finished
> ;   caught 1 STYLE-WARNING condition
> BAZ
> * (baz 21)
> debugger invoked on a UNDEFINED-FUNCTION @B800000C2C in thread
> #<THREAD tid=25129 "main thread" RUNNING {1200BD0003}>:
>    The function SB-KERNEL:%MAKE-DOUBLE-FLOAT is undefined.
>
>
>
>
> _______________________________________________
> Sbcl-bugs mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-bugs

[Sbcl-bugs] SB-KERNEL:%MAKE-DOUBLE-FLOAT undefined in SCALE-FLOAT / space 0

[Eric M. <eri...@ri...>]

Hi,

This is from random-integer testing on AMD64.

* (lisp-implementation-version)
"2.5.6.62-95edde758"
* (defun baz (a) (declare (optimize (space 0)) (type (member 684016 21) a)) (scale-float 1d0 a))
; in: DEFUN BAZ
;     (SCALE-FLOAT 1.0d0 A)
;
; caught STYLE-WARNING:
;   Lisp error during constant folding:
;   The function SB-KERNEL:%MAKE-DOUBLE-FLOAT is undefined.
;
; compilation unit finished
;   caught 1 STYLE-WARNING condition
BAZ
* (baz 21)
debugger invoked on a UNDEFINED-FUNCTION @B800000C2C in thread
#<THREAD tid=25129 "main thread" RUNNING {1200BD0003}>:
   The function SB-KERNEL:%MAKE-DOUBLE-FLOAT is undefined.

[Sbcl-bugs] BUG: full call to SB-VM::*-MODFX

[Eric M. <eri...@ri...>]

Hi,

This is from random-integer testing on AMD64.


* (lisp-implementation-version)
"2.5.6.62-95edde758"
* (defun foo (a)
     (declare (type (integer -4 9) a))
     (mask-field (byte 10 5)
                 (* 42 (ash (eval 42) (shiftf a -3)))))
debugger invoked on a SB-INT:BUG in thread
#<THREAD tid=26503 "main thread" RUNNING {1200BD0003}>:
     full call to SB-VM::*-MODFX
   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/>.

(SB-INT:BUG "full call to ~S" SB-VM::*-MODFX)
0] backtrace
Backtrace for: #<SB-THREAD:THREAD tid=26503 "main thread" RUNNING {1200BD0003}>
0: (SB-INT:BUG "full call to ~S" SB-VM::*-MODFX)
1: (SB-C::PONDER-FULL-CALL #<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME SB-VM::*-MODFX :TYPE #1=#<SB-KERNEL:FUN-TYPE (FUNCTION (INTEGER INTEGER) (VALUES FIXNUM &OPTIONAL))> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {120290D7E3}> {12028F46A3}> :ARGS (#<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME ASH :TYPE #2=#<SB-KERNEL:FUN-TYPE #> :DEFINED-TYPE #2# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {12028F4993}> {12028F4A73}> :ARGS (#<SB-C::COMBINATION :FUN # :ARGS # {120290DD03}> #<SB-C::REF :%SOURCE-NAME A :LEAF # {12028F6FF3}>) {12028F4AE3}> #<SB-C::REF  :LEAF #<SB-KERNEL:CONSTANT :VALUE 42 {12028F4843}> {12028F48A3}>) {12028F4713}>)
2: (SB-C::IR2-CONVERT-FULL-CALL #<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME SB-VM::*-MODFX :TYPE #1=#<SB-KERNEL:FUN-TYPE (FUNCTION (INTEGER INTEGER) (VALUES FIXNUM &OPTIONAL))> :DEFINED-TYPE #1# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {120290D7E3}> {12028F46A3}> :ARGS (#<SB-C::COMBINATION :FUN #<SB-C::REF  :LEAF #<SB-C::GLOBAL-VAR :%SOURCE-NAME ASH :TYPE #2=#<SB-KERNEL:FUN-TYPE #> :DEFINED-TYPE #2# :WHERE-FROM :DECLARED :KIND :GLOBAL-FUNCTION {12028F4993}> {12028F4A73}> :ARGS (#<SB-C::COMBINATION :FUN # :ARGS # {120290DD03}> #<SB-C::REF :%SOURCE-NAME A :LEAF # {12028F6FF3}>) {12028F4AE3}> #<SB-C::REF  :LEAF #<SB-KERNEL:CONSTANT :VALUE 42 {12028F4843}> {12028F48A3}>) {12028F4713}> #<SB-C::IR2-BLOCK  :START-VOP #<SB-C::VOP :INFO SB-C:MOVE :ARGS #<SB-C:TN-REF :TN #<SB-C:TN #:G7!1 :NORMAL> :WRITE-P NIL :VOP SB-C:MOVE> :RESULTS #<SB-C:TN-REF :TN #<SB-C:TN t2 :NORMAL> :WRITE-P T :VOP SB-C:MOVE>> :LAST-VOP #<SB-C::VOP :INFO SB-C:MOVE :ARGS #<SB-C:TN-REF :TN #<SB-C:TN t3[RDX(d)] :NORMAL> :WRITE-P NIL :VOP SB-C:MOVE> :RESULTS #<SB-C:TN-REF :TN #<SB-C:TN t4 :NORMAL> :WRITE-P T :VOP SB-C:MOVE>> {120293EA43}>)
3: (SB-C::IR2-CONVERT-BLOCK #<SB-C::CBLOCK 4 :START c1 {12029385C3}>)

[Sbcl-bugs] SB-ALIEN:WITH-ALIEN errors using bound variable in interpreter mode.

[Lee J. H. <jia...@ou...>]

Hi,

In compiler mode, these are straight forward and working as expected. 
But when doing the same in interpreter mode, one faces with lots of 
unexpected type errors.

     CL-USER> (setf sb-ext:*evaluator-mode* :compile)
     :COMPILE

     ;;; With initial value
     CL-USER> (with-alien ((foo integer 3))
                (values foo (addr foo)))
     3
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7F99C356FFF8
         :TYPE (* (SB-ALIEN:SIGNED 64))>

     ;;; Without initial value, but given via SETF.
     CL-USER> (with-alien ((foo integer))
                (setf foo 3)
                (values foo (addr foo)))
     3
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7F99C356FFF8
         :TYPE (* (SB-ALIEN:SIGNED 64))>


In interpreter mode, when initial values are provided, there is no way 
to use the bound variable in the body due to type errors:

     CL-USER> (setf sb-ext:*evaluator-mode* :interpret)
     :INTERPRET

     ;;; With initial value
     CL-USER> (with-alien ((foo integer 3))
                foo)
     ; Evaluation aborted on #<TYPE-ERROR expected-type:
         SB-ALIEN-INTERNALS:ALIEN-VALUE datum: 3>.

     CL-USER> (with-alien ((foo integer 3))
                foo
                100)
     ; Evaluation aborted on #<TYPE-ERROR expected-type:
         SB-ALIEN-INTERNALS:ALIEN-VALUE datum: 3>.

     CL-USER> (with-alien ((foo integer 3))
                (addr foo))
     ; Evaluation aborted on #<TYPE-ERROR expected-type:
         (ALIEN (* T)) datum: 3>.


A workaround is to assign initial value via SETF. But naive SETF is not 
the right way. It seems to work, but erred with further usage. It 
appears that SETF has changed the value type.

     ;;; Without initial value
     ;; Seems to work
     CL-USER> (with-alien ((foo integer))
                (setf foo 3))
     3

     ;; Erred with further usage
     CL-USER> (with-alien ((foo integer))
                (setf foo 3)
                foo)
     ; Evaluation aborted on #<TYPE-ERROR expected-type:
         SB-ALIEN-INTERNALS:ALIEN-VALUE datum: 3>.

     CL-USER> (with-alien ((foo integer))
                (setf foo 3)
                (addr foo))
     ; Evaluation aborted on #<TYPE-ERROR expected-type:
         (ALIEN (* T)) datum: 3>.


Then, I realise the correct but tedious way to SETF via `(DEREF (ADDR 
name))`. I'd expect this to be handled internally by the WITH-ALIEN.

     CL-USER> (with-alien ((foo integer))
                (setf (deref (addr foo)) 3)
                (values foo (addr foo)))
     3
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X559CD95D29A0
         :TYPE (* (SB-ALIEN:SIGNED 32))>


In short, I'd expect SB-ALIEN:WITH-ALIEN to behave consistently in both 
compiler and interpreter mode.


Environment:
SBCL 2.5.6
Linux x86_64


Many thanks,
Jia Hong

[Sbcl-bugs] SB-ALIEN:MAKE-ALIEN dynamic array allocation error when NIL is used for variadic size.

[Lee J. H. <jia...@ou...>]

Hi,

As per SBCL manual 
(http://www.sbcl.org/manual/index.html#Foreign-Type-Specifiers):

 > An array whose first dimension is variable may be specified by using 
`nil` as the first dimension. [...] Dynamic arrays can only be allocated 
using `sb-alien:make-alien`.

I'd expect this to allocate an array of dimensions (30 3 3), but it 
fails with type error.

     CL-USER> (make-alien (array c-string nil 3 3) 30)
     ; Evaluation aborted on #<TYPE-ERROR expected-type: (UNSIGNED-BYTE 
62) datum: NIL>.

I believe this is an error in type checking because if I pass in 
anything else, it'll error out "The first dimension is not a 
non-negative fixnum or *NIL*" (emphasis mine).

     CL-USER> (make-alien (array c-string 'abc 3 3) 30)
     ; Evaluation aborted on #<SIMPLE-ERROR "The first dimension is not 
a non-negative fixnum or NIL: ~S" {1200F766C3}>.


Environment:
SBCL 2.5.6
Linux x86_64


Many thanks,
Jia Hong

[Sbcl-bugs] SB-ALIEN:MAKE-ALIEN ignores the size argument when a variable is passed in.

[Lee J. H. <jia...@ou...>]

Hi,

I've found an inconsistent behaviour of SB-ALIEN:MAKE-ALIEN with its 
size argument.

With integer literal, the first dimension is overridden.

     CL-USER> (make-alien (array c-string 3 3 3) 30)
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X55A164252A90 :TYPE (*
(ARRAY
SB-ALIEN:C-STRING
30 3 3))>

With (lexical/dynamic) variables, it is ignored. I'll expect it to 
override the first dimension as well.

     ;; Lexical variable
     CL-USER> (let ((size 30))
                (make-alien (array c-string 3 3 3) size))
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X55A164252A90 :TYPE (*
(ARRAY
SB-ALIEN:C-STRING
                                                                  3 3 
3))>       ; expected to be dimension (30 3 3) as before
     ;; Dynamic variable
     CL-USER> (defvar *size* 30)
     *SIZE*
     CL-USER> (make-alien (array c-string 3 3 3) *size*)
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X55A164252A90 :TYPE (*
(ARRAY
SB-ALIEN:C-STRING
                                                                  3 3 3))>

Environment:
SBCL 2.5.6
Linux x86_64


Many thanks,
Jia Hong

[Sbcl-bugs] Recursive `#.` forms that mismatch a structure slot type can cause infinite recursion in reading

[Bohong H. <boh...@qq...>]

Hello SBCL developers,

The following code:


    (defstruct a
      (a nil :type (or a null)))

    (defun recursive-a ()
      (let ((a (make-a)))
        (setf (a-a a) a)))

    (read-from-string "#S(A :A (#.(RECURSIVE-A)))")


can exhaust the control stack during execution:


    Control stack exhausted (no more space for function call frames).
    This is probably due to heavily nested or infinitely recursive function
    calls, or a tail call that SBCL cannot or has not optimized away.

    PROCEED WITH CAUTION.
       [Condition of type SB-KERNEL::CONTROL-STACK-EXHAUSTED]

    Restarts:
     0: [RETRY] Retry SLY interactive evaluation request.
     1: [*ABORT] Return to SLY's top level.
     2: [ABORT] abort thread (#<THREAD tid=5613 "slynk-worker" RUNNING {1201E9DC13}>)

    Backtrace:
     0: (SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
     1: ("foreign function: call_into_lisp_")
     2: ("foreign function: post_signal_tramp")
     3: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
     4: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
     5: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106A3017B}>)
     6: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
     7: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
     8: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106A3030B}>)
     9: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
    10: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
    11: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106A3049B}>)
    12: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))

    ...

    15134: (SB-IMPL::SHARP-EQUAL-VISIT #1=#S(A :A #1#) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106C1C92B}>)
    15135: (SB-IMPL::CONTAINS-MARKER #1=#S(A :A #1#))
    15136: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) #1=#S(A :A #1#))
    15137: ((LABELS SB-IMPL::RECURSE :IN SB-IMPL::SHARP-EQUAL-VISIT) (#1=#S(A :A #1#)))
    15138: (SB-IMPL::SHARP-EQUAL-VISIT (#1=#S(A :A #1#)) #<FUNCTION (FLET SB-IMPL::PROCESS :IN SB-IMPL::CONTAINS-MARKER) {1200CD165B}> #<FUNCTION (FLET SB-IMPL::VISIT :IN SB-IMPL::CONTAINS-MARKER) {7F4106C1CB3B}..
    15139: (SB-IMPL::CONTAINS-MARKER (#1=#S(A :A #1#)))
    15140: ((LAMBDA (SB-IMPL::C) :IN SB-IMPL::SHARP-S) #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
    15141: (SB-KERNEL::%SIGNAL #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
    15142: (ERROR #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
    15143: (SB-KERNEL:WITH-SIMPLE-CONDITION-RESTARTS ERROR NIL #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
    15144: ((LABELS SB-KERNEL::TRY :IN SB-KERNEL::RESTART-TYPE-ERROR) #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))>)
    15145: (SB-KERNEL::RESTART-TYPE-ERROR (OR A NULL) #<TYPE-ERROR expected-type: (OR A NULL) datum: (#1=#S(A :A #1#))> -60)
    15146: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #X7F4106C1D040) #<unused argument>)
    15147: ("foreign function: call_into_lisp_")
    15148: ("foreign function: funcall2")
    15149: ("foreign function: interrupt_internal_error")
    15150: ("foreign function: #x55F1FE926B41")
    15151: (MAKE-A :A (#1=#S(A :A #1#)))
    15152: (SB-IMPL::SHARP-S #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> #\S NIL)
    15153: (SB-IMPL::READ-MAYBE-NOTHING #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> #\#)
    15154: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> T (NIL) T)
    15155: (SB-IMPL::%READ-PRESERVING-WHITESPACE #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> T (NIL) NIL)
    15156: (READ #<SB-IMPL::STRING-INPUT-STREAM {12020A83A3}> T NIL NIL)
    15157: (SB-IMPL::%READ-FROM-STRING/SAFE "#S(A :A (#.(RECURSIVE-A)))" T NIL 0 NIL NIL)
    15158: (SB-INT:SIMPLE-EVAL-IN-LEXENV (READ-FROM-STRING "#S(A :A (#.(RECURSIVE-A)))") #<NULL-LEXENV>)
    15159: (EVAL (READ-FROM-STRING "#S(A :A (#.(RECURSIVE-A)))"))


This issue appears to be an issue only in recent versions of SBCL.
Thank you in advance for taking the time to look into this issue.


Best regards,

Bohong Huang