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
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
off
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
