Bug 272670 - lang/ecl: ECL crashes instead of signaling condition on stack overflow
Summary: lang/ecl: ECL crashes instead of signaling condition on stack overflow
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jimmy Olgeni
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-23 03:58 UTC by Kevin Zheng
Modified: 2023-07-23 18:03 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (olgeni)


Attachments
Minimal reproduction (36 bytes, text/plain)
2023-07-23 03:58 UTC, Kevin Zheng
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Zheng 2023-07-23 03:58:43 UTC
Created attachment 243557 [details]
Minimal reproduction

ECL has a stack overflow detection mechanism that is supposed to signal a stack overflow condition to allow graceful recovery on stack overflow. This does not appear to be working on the system I tested this on, using the ECL from latest packages.

Steps to reproduce:

1. Get stack-overflow.lisp (attached)

2. ecl --load stack-overflow.lisp

pid 23924 comm ecl has trashed its stack, killing
terminated by signal SIGILL (Illegal instruction)

I can't tell if this is the compiler stack canary, or the stack guard packages, that is killing this process.

Re-running through truss seems to suggest that it's the OS killing it:

mmap(0x805b9b000,65536,PROT_READ|PROT_WRITE,MAP_PRIVATE,3,0x0) = 34455793664 (0x805b9b000)
mmap(0x805bab000,65536,PROT_READ|PROT_WRITE,MAP_PRIVATE,3,0x0) = 34455859200 (0x805bab000)
SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdfffe668
pid 23984 comm ecl has trashed its stack, killing
_umtx_op(0x80023c080,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call'

But I can't really tell and don't want to jump to conclusions.

> uname -a
FreeBSD foxtrot 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64

> pkg info -f ecl
ecl-21.2.1_1
Name           : ecl
Version        : 21.2.1_1
Installed on   : Wed Mar 22 20:43:51 2023 PDT
Origin         : lang/ecl
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : lisp lang
Licenses       : LGPL20
Maintainer     : olgeni@FreeBSD.org
WWW            : https://common-lisp.net/project/ecl/main.html
Comment        : ANSI Common Lisp implementation
Options        :
        ASDF           : on
        DFFI           : on
        SAGE           : on
        SOCKETS        : on
        THREADS        : on
        X11            : off
Shared Libs required:
        libgmp.so.10
        libgc.so.1
        libgc-threaded.so.1
        libffi.so.8
        libatomic_ops.so.1
Shared Libs provided:
        libecl.so.21.2
Annotations    :
        FreeBSD_version: 1301000
Comment 1 John F. Carr 2023-07-23 14:46:23 UTC
I can not reproduce this on FreeBSD 13.2-CURRENT amd64.  I see a message "Condition of type: STACK-OVERFLOW".  The process does not receive any SIGBUS or SIGSEGV signals.

The "trashed its stack" message comes from exec_machdep.c function sendsig when it can not write to memory on the stack to which the signal is being delivered.  The program is terminated with SIGILL.  If the C stack has overflowed the program must have used sigaltstack to request signal handling on a different stack, otherwise any signal will cause this crash.
Comment 2 Kevin Zheng 2023-07-23 18:03:16 UTC
(In reply to John F. Carr from comment #1)
Thanks for writing in trying to reproduce the issue.

I've looked more carefully and realized that I've been running a locally-built version of the ECL from ports, and not the version from the latest binary packages.

When I uninstall ECL and install from packages, I indeed get the STACK-OVERFLOW signaled. However, when I uninstall and compile/build the latest version from ports, I again run into "ecl has trashed its stack, killing". I assume that something in my environment is leaking into the package build causing ECL to be built differently. I'll try to see why this is.