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