Hi Paul,
thank you for testing it. My mistake: the fixes for your report were not
yet in *SVN 2136* (which only contained other changes), although my reply
said so. They are in *SVN 2137,* which is on Savannah now.
Summary
-------
Fixed: 1 (#1)
Fixed
-----
#1 "listen socket has died unexpectedly" and the APserver that keeps
running: please update to *SVN 2137.* The changes are the ones
described
in my previous reply: APserver no longer probes its listening socket,
and the interpreter uses a fresh socket for every attempt to connect
to APserver.
Since an APserver from an earlier session may still be running (and
keep printing its messages to the terminal in which it was started),
please run "killall APserver" once before testing.
*SVN 2137* also contains the new ]STATUS command (and apl --status),
which shows in its "APserver" row whether the interpreter could
connect to APserver, and if not, why not.
I can only test on Linux, so it would be great if you could check it on
macOS again.
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/7/26 23:22, Paul Rockwell 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
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
