One step forward, one step back. The changes to APserver appear to work in SVN 2136. The error messages no longer appear, and the APserver process starts when I start the interpreter, and stops when the interpreter is stopped. That's the good news.
But here's the not-so-good news... SVN 2136 lookis like it introduces a new module src/CrashDump.cc <http://crashdump.cc/>.. (or at least it was not present in SVN 2136 which was the prior version I downloaded). CrashDump.cc <http://crashdump.cc/> does not compile under macOS as-is. The error messages are: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O2 -I ./sql -I /Users/paulrockwell/Documents/Build/GNU_APL -O2 -I/opt/local/include -std=gnu++17 -I /Users/paulrockwell/Documents/Build/GNU_APL -MT apl-CrashDump.o -MD -MP -MF .deps/apl-CrashDump.Tpo -c -o apl-CrashDump.o `test -f 'CrashDump.cc' || echo './'`CrashDump.cc In file included from CrashDump.cc:28: /Volumes/MyPassport/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/ucontext.h:51:2: error: The deprecated ucontext routines require _XOPEN_SOURCE to be defined 51 | #error The deprecated ucontext routines require _XOPEN_SOURCE to be defined | ^ Adding a #include _XOPEN_SOURCE to CrashDump.cc <http://crashdump.cc/> gets by this error, but a new error appears: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O2 -I ./sql -I /Users/paulrockwell/Documents/Build/GNU_APL -O2 -I/opt/local/include -std=gnu++17 -I /Users/paulrockwell/Documents/Build/GNU_APL -MT apl-CrashDump.o -MD -MP -MF .deps/apl-CrashDump.Tpo -c -o apl-CrashDump.o `test -f 'CrashDump.cc' || echo './'`CrashDump.cc In file included from CrashDump.cc:46: In file included from ./Backtrace.hh:32: In file included from ./Common.hh:49: In file included from /Volumes/MyPassport/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/csignal:49: /Volumes/MyPassport/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:72:42: error: use of undeclared identifier 'NSIG' 72 | extern __const char *__const sys_signame[NSIG]; | ^~~~ /Volumes/MyPassport/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/signal.h:73:42: error: use of undeclared identifier 'NSIG' 73 | extern __const char *__const sys_siglist[NSIG]; | ^~~~ Claude indicates that NSIG, sys_signame, and sys_siglist are BSD/Darwin extensions, not POSIX, so they vanish when _XOPEN_SOURCE is included to fix the first issue. This diff contains the #include's that I was able to find (with Claude's help) that allow the compiliation of CrashDump.cc <http://crashdump.cc/> to compile successfully: % svn diff src/CrashDump.cc Index: src/CrashDump.cc =================================================================== --- src/CrashDump.cc (revision 2139) +++ src/CrashDump.cc (working copy) @@ -17,6 +17,8 @@ You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ +#define _XOPEN_SOURCE 500 +#define _DARWIN_C_SOURCE #include <errno.h> #include <fcntl.h> Claude also indicates that the ucontext routines were depercated by macOS as of macOS 10.6 Snow Leopard in 2009, and that while glibc in Linux still supports it, POSIX marked them obsolescent in 2004 and removed them from the standard in 2008. - paul > On Oct 7, 2026, at 5:22 PM, Paul Rockwell <[email protected]> wrote: > > SVN'd up to 2136. Issue still exists. I'll do some additional debugging and > see if I can get any more info. > > - Paul > > >> On Oct 7, 2026, at 7:39 AM, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> >> wrote: >> >> Hi Paul, >> >> thank you for your report and for tracking it down to listen_sock(). >> It is dealt with in SVN 2136. >> >> Summary >> ------- >> Fixed: 2 (#1, #2) >> Not a bug: 1 (#3) >> >> Fixed >> ----- >> #1 "listen socket has died unexpectedly": APserver no longer probes its >> listening socket with read(). That probe was meaningless (macOS fails >> it with ENOTCONN, as you found), had no corrective action, and >> printed its message on every pass of APserver's main loop, i.e. at >> least once a second. >> >> #2 "::connect() to supposedly existing APserver failed: Socket is >> already connected" (and the APserver that keeps running after the >> interpreter has exited): the interpreter retried ::connect() on the >> same socket after a failed attempt. After a failed ::connect() the >> state of a socket is unspecified; Linux accepts another ::connect() >> on it, but macOS does not. As a consequence your interpreter never >> connected to the APserver it had just started, and APserver, which >> exits only when its last connection is closed, kept running. Every >> attempt now uses a fresh socket. >> >> In addition, if the connection to APserver fails anyway, the >> interpreter now continues as if shared variables were disabled >> (instead of reporting "Svar_DB not connected" later on). >> >> I could only verify that nothing breaks on Linux, where the problem >> does not occur. It would be great if you could check the fix on macOS. >> >> Not a bug >> --------- >> #3 Shared variables disabled by default: this is already a user >> preference. "SharedVars Disabled" in the system-wide or in your own >> preferences file disables them (as you already do), and the command >> line options --noSV and --SV override the preference for a single >> run. The default stays enabled for compatibility with existing >> applications that use ⎕SVO. >> >> The new debug command ]STATUS (or the command line option >> apl --status) shows whether shared variables are enabled, whether >> the connection to APserver works, and if not, why not (e.g. which >> preferences file and line disabled them). It does the same for the >> other optional features of GNU APL. >> >> Best Regards, >> Jürgen >> >> PS: The analysis of your report and the resulting changes were made with >> the help of Claude Code (Anthropic). All changes were reviewed by me and >> verified against the GNU APL testcases before being committed. >> >> >> On 10/5/26 20:10, Paul Rockwell wrote: >>> I preface this by understanding that shared variables ((⎕SVO,etc) are >>> considered an obsolete feature of GNU APL. I have my preferences set so >>> that APserver is never started by default. But I've come across the >>> following when using the default GNU APL behavior of enabling shared >>> variable support. >>> >>> When starting the interpreter in SVN 2133 on macOS 26 and 27 with the >>> shared variable support enabled, I'm greeted with the following: >>> >>> % apl --SV >>> /usr/local/bin/APserver: listen socket has died unexpectedly >>> /usr/local/bin/APserver: listen socket has died unexpectedly >>> ::connect() to supposedly existing APserver failed: Socket is already >>> connected >>> >>> ______ _ __ __ __ ___ ____ __ >>> / ____// | / // / / / / | / __ \ / / >>> / / __ / |/ // / / / / /| | / /_/ // / >>> / /_/ // /| // /_/ / / ___ | / ____// /___ >>> \____//_/ |_/ \____/ /_/ |_|/_/ /_____/ >>> >>> Welcome to GNU APL version 2.0 / SVN: 2133M >>> >>> Copyright © 2008-2026 Dr. Jürgen Sauermann >>> Banner by FIGlet: www.figlet.org >>> <http://www.figlet.org/> >>> >>> This program comes with ABSOLUTELY NO WARRANTY; >>> for details run: apl --gpl. >>> >>> This program is free software, and you are welcome to redistribute it >>> according to the GNU General Public License (GPL) version 3 or later. >>> >>> Svar_DB not connected in Svar_DB::is_registered_id() (APserver not running; >>> shared variables unavailable) >>> /usr/local/bin/APserver: listen socket has died unexpectedly >>> /usr/local/bin/APserver: listen socket has died unexpectedly >>> ) /usr/local/bin/APserver: listen socket has died unexpectedly >>> o ff >>> >>> Goodbye. >>> Session duration: 4.67723 seconds >>> paulrockwell@Upstairs ~ % /usr/local/bin/APserver: listen socket has died >>> unexpectedly >>> k/usr/local/bin/APserver: listen socket has died unexpectedly >>> killall/usr/local/bin/APserver: listen socket has died unexpectedly >>> AP/usr/local/bin/APserver: listen socket has died unexpectedly >>> serv/usr/local/bin/APserver: listen socket has died unexpectedly >>> er >>> >>> The error messages from APserver continue after I stop the interpreter >>> because the /usr/local/bin/APserver process is still running in the >>> background. I have to locate and kill the process manually. >>> >>> Debugging the source code by executing APserver manually like GNU APL is >>> doing behind the scenes revealed that the followng code in >>> src/APs/APserver.cc <http://apserver.cc/> function listen_sock() is >>> returning failure: >>> >>> // read() cannot be used to probe a Winsock SOCKET on Windows -- >>> // it is not a CRT file descriptor, only recv()/send()/ioctlsocket() >>> // are valid on it -- so this always (falsely) reported the listen >>> // socket, and then any freshly accepted connection, as dead on >>> // every pass, immediately closing real connections again via >>> // close_fd() below. A dead listen socket has no corrective action >>> // here anyway (just the message); on Windows a dead per-connection >>> // socket is still caught by the normal recv() return value once >>> // real data-handling code runs on it later in the loop, the same >>> // way most Windows socket servers detect a disconnect. >>> if (0 != read(listen_sock, &dummy, 0)) >>> cerr << prog << ": listen socket has died unexpectedly" << endl; >>> >>> >>> The read() on listen_sock is returning error code 57 (ENOTCONN), in case >>> that helps. >>> >>> I've included the configure output, config.log, and config.h so you can see >>> how GNU APL has been configured. >>> >>> A side request: If you consider shared variable support to be obsolete, >>> could the global GNU APL preferences be configured so that shared variable >>> support is disabled by default? >>> >>> >>> >>> >>> - Paul Rockwell >>> >> >
