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