Mute ws_discard_input()

alanbur · May 18, 2026, 1:35pm

When using the GUI debugger there’s often a continuous stream of messages from ws_discard_input() that seem to serve no useful purpose and make the terminal interface completely unusable. This patch fixes that. Patch is against 10.1.7. Submitted as .c because .patch won’t attach.

ws_discard_input.patch.c (2.7 KB)

EricGT · May 18, 2026, 1:54pm

Thanks for noting that and for uploading the file as .c.

The reason .patch files are not allowed here is that the official way to submit changes to the SWI-Prolog codebase is through a Git pull request.

jan · May 18, 2026, 2:24pm

How do I reproduce this? This message happens if the GUI is waiting for a user event but instead you type something in the terminal. It seems a good idea to warn the user that it is not waiting for the terminal, so there is no point typing there (possibly with a clearer messages).

alanbur · May 18, 2026, 5:13pm

I think this probably needs wrapping so the message is only output in debug mode or somesuch so I don’t think it is PR-ready, it’s more an indicator of where the problem is.

alanbur · May 18, 2026, 5:16pm

The problem is that there’s a long stream of them, not just one, which means if you’ve typed anything in the terminal, it’s gone. If it’s a GUI-wait shouldn’t it be displayed in the GUI rather than scribbling on the text console?

peter.ludemann · May 18, 2026, 6:18pm

Patches can be emailed to bugs@swi-prolog.org as described in How to submit patches?

EricGT · May 18, 2026, 6:39pm

Thanks.

I can add patch so those files types can be uploaded in less than a minute. Just need Jan’s approval.

jan · May 18, 2026, 6:59pm

The route of choice is GitHub pull requests. If not the result of git format-patch sent to bugs@swi-prolog.org. All the rest is emergency only.

jan · May 18, 2026, 7:00pm

That should be fixed, but first I need to be able to reproduce it to access the context in which it needs fixing. So, what OS? swipl or swipl-win? What exactly are you doing?

EricGT · May 18, 2026, 7:03pm

Per Jan, will not be ading patch as a file type that can be uploaded here.

alanbur · May 20, 2026, 3:49pm

This is 10.1.7 on Linux, built from source, swipl rather than swipl-win. Stepping through code after a gspy. It seems to start randomly, but once it does I get a continuous stream of Confirmer running; discarding input ...failed messages that instantly overflow the terminal buffer,

If I ^C I see the following:

Action (h for help) ? goals
     [47] pce:xpce_console(_23378, _23380, _23382)
     [45] pce_principal:get(@11783562242084/prolog_debugger, confirm, _18800)
     [44] Get-method on @11783562242084/prolog_debugger: prolog_debugger<-action --> _18800
     [42] pce_principal:get(@11783562242084/prolog_debugger, action, _18780)
     [39] pce_prolog_tracer:action_(_1132)
Action (h for help) ? C-stack trace labeled "INT":
  [0] save_backtrace() at /data2/tmp/swipl-devel-10.1.7/src/os/pl-cstack.c:334 [0x7f0b67b5bf68]
  [1] interruptHandler() at /data2/tmp/swipl-devel-10.1.7/src/pl-trace.c:2023 [0x7f0b67a95ba0]
  [2] dispatch_signal() at /data2/tmp/swipl-devel-10.1.7/src/pl-setup.c:594 [0x7f0b67b451e2]
  [3] handleSignals___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-setup.c:1252 [0x7f0b67b1bed8]
  [4] PL_next_solution_guarded___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-vmi.c:1941 [0x7f0b67aff1b3]
  [5] PL_next_solution___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-wam.c:3574 [0x7f0b67afa2b6]
  [6] PL_call_predicate() at /data2/tmp/swipl-devel-10.1.7/src/pl-fli.c:4539 [0x7f0b67b2e614]
  [7] XPCE_OUTPUT() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/swipl/interface.c:3026 (discriminator 1) [0x7f0b66003a23]
  [8] pl_Cvprintf() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/swipl/interface.c:3060 [0x7f0b66003adf]
  [9] Cprintf() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/src/itf/interface.c:904 [0x7f0b65f07816]
  [10] ws_discard_input() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/src/sdl/sdlevent.c:864 [0x7f0b66001a61]
  [11] SdlWaitConfirmFrame() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/src/win/frame.c:212 [0x7f0b65fe12c1]
  [12] pceExecuteGoal() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/src/ker/passing.c:820 [0x7f0b65f20a84]
  [13] invoke() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/swipl/interface.c:2142 (discriminator 1) [0x7f0b66008866]
  [14] pl_get() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/swipl/interface.c:2190 [0x7f0b66009021]
  [15] PL_next_solution_guarded___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-vmi.c:4384 (discriminator 2) [0x7f0b67a543bc]
  [16] PL_next_solution___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-wam.c:3574 [0x7f0b67afa2b6]
  [17] PL_call_predicate() at /data2/tmp/swipl-devel-10.1.7/src/pl-fli.c:4539 [0x7f0b67b2e614]
  [18] invoke() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/swipl/interface.c:2091 [0x7f0b66008cfa]
  [19] pl_get() at /data2/tmp/swipl-devel-10.1.7/packages/xpce/swipl/interface.c:2190 [0x7f0b66009021]
  [20] PL_next_solution_guarded___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-vmi.c:4384 (discriminator 2) [0x7f0b67a543bc]
  [21] PL_next_solution___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-wam.c:3574 [0x7f0b67afa2b6]
  [22] callProlog() at /data2/tmp/swipl-devel-10.1.7/src/pl-pro.c:535 [0x7f0b67b141fe]
  [23] pl_notrace1_va() at /data2/tmp/swipl-devel-10.1.7/src/pl-pro.c:403 [0x7f0b67a82119]
  [24] PL_next_solution_guarded___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-vmi.c:4343 [0x7f0b67afad07]
  [25] PL_next_solution___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-wam.c:3574 [0x7f0b67afa2b6]
  [26] traceInterception() at /data2/tmp/swipl-devel-10.1.7/src/pl-trace.c:1591 (discriminator 1) [0x7f0b67a96449]
  [27] PL_next_solution_guarded___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-vmi.c:2016 (discriminator 1) [0x7f0b67a50597]
  [28] PL_next_solution___LD() at /data2/tmp/swipl-devel-10.1.7/src/pl-wam.c:3574 [0x7f0b67afa2b6]
  [29] query_loop() at /data2/tmp/swipl-devel-10.1.7/src/pl-pro.c:171 [0x7f0b67b3ffe3]
  [30] prologToplevel() at /data2/tmp/swipl-devel-10.1.7/src/pl-pro.c:662 [0x7f0b67b3fe7d]
  [31] PL_toplevel() at /data2/tmp/swipl-devel-10.1.7/src/pl-fli.c:5005 [0x7f0b67b5493a]
  [32] ??? [0x55bc6eda60c0]
  [33] __libc_start_call_main() at ./csu/../sysdeps/nptl/libc_start_call_main.h:74 [0x7f0b6785cca8]
  [34] call_init() at ./csu/../csu/libc-start.c:128 [0x7f0b6785cd65]
  [35] ??? [0x55bc6eda6101]

Dunno if that helps any, I can’s spot any obvious trigger for it to start happening. Once it has started, moving focus to the debugger window seems to make it worse, but it’s difficult to tell as the messages are being produced so quickly.

alanbur · May 20, 2026, 5:31pm

The problem appears to be deeper than just the error message. I added diagnostics that print the fd on failure, and correlated this with strace output from the same run. What happens is:

Some socket/HTTP activity uses fd 7.
xpce’s ws_dispatch() is called with that stream/fd and records fd 7 as dispatch state: both in the static dispatch_fd and in the associated SDL fd watch.
The TCP socket is closed.
fd 7 is then reused for unrelated file loads and closed again.
The debugger confirm loop later dispatches through DEFAULT, which reuses stale dispatch state for fd 7.
The kernel correctly reports POLLNVAL, and the repeated messages result.

The root cause seems to be that ws_dispatch() persists the fd passed to it. That fd may be a borrowed external fd from SWI’s dispatch hook, for example a socket stream Prolog is waiting on. It is valid to poll such an fd during that specific dispatch call so the GUI remains responsive while Prolog waits for stream input. But it should not become persistent dispatch state used by later DEFAULT calls.

The default dispatch fd/watch should be kept separate from external fds that are only used for temporary wakeup. External fds can be closed by their owner and later report POLLNVAL; they should not be cached globally by xpce. Conversely, a failure on an xpce-owned fd/watch would probably indicate a bug.

One danger with the current implementation is that ws_discard_input() could conceivably be called on a non-console fd, thereby discarding input from a file or network stream. The current implementation attempts to guard against this by checking for a console, but that check is a) Windows-only and b) broken for the stale-fd case described above.

I think the least intrusive fix is to make the default dispatch fd/watch explicit, and only set the cached value there. Then remove persistent caching from ws_dispatch() itself. ws_dispatch(input, timeout) can still poll the supplied fd as a temporary wake condition, but it should not persist it for later DEFAULT calls.

No was permanently harmed in the making of this post, just taunted a bit.

alanbur · May 21, 2026, 9:33am

Bug logged, PR to follow:

github.com/SWI-Prolog/swipl-devel

ws_dispatch() caches external stream fds as the default dispatch fd

opened 09:31AM - 21 May 26 UTC

alanbur

I hit a terminal flood from the graphical debugger after stopping at a gspy/1 sp…y point: ``` Confirmer running; discarding input ...failed Confirmer running; discarding input ...failed ``` This instantly overflowed the terminal buffer. Adding diagnostics around the failed input check showed repeated `POLLNVAL` on the cached dispatch fd. I correlated this with `strace` output from the same run. The sequence was: 1. Some socket/HTTP activity used fd 7. 2. xpce’s `ws_dispatch()` was called with that fd. 3. `ws_dispatch()` cached fd 7 in the static `dispatch_fd`. 4. The TCP socket was closed. 5. fd 7 was later reused for unrelated file loads and closed again. 6. The debugger confirm loop later used `DEFAULT`, which reused the now closed `dispatch_fd` = 7. 7. The kernel correctly reported `POLLNVAL`, causing the repeated messages. The root cause appears to be that ws_dispatch() caches any non-`NO_WAITABLE` fd: ``` if ( fd != NO_WAITABLE ) dispatch_fd = fd; ``` That is too broad. The fd passed to `ws_dispatch()` may be an external fd from SWI’s dispatch hook, such as a socket stream that Prolog is waiting on. It is valid to poll that fd during that dispatch call so the GUI remains responsive, but it must not become xpce’s default dispatch fd. The distinction seems to be: * The console/default dispatch input may be persistent and reused by `DEFAULT`; * External streams/fds are temporary wakeup sources only; * External fds must not be saved in `dispatch_fd`. Otherwise a closed/reused socket fd can poison the default dispatch state, and code such as `ws_discard_input()` may later poll or attempt to discard input from an unrelated and possibly closed fd. In my case the guard failed with `POLLNVAL`, but the broader ownership issue is that `dispatch_fd` is set unconditionally from unrelated streams.

alanbur · May 21, 2026, 11:11am

As I note in the PR, this was heavily AI-assisted - caveat emptor…

github.com/SWI-Prolog/packages-xpce

1494 ws_dispatch() caches external stream fds as the default dispatch fd (#55)

master ← alanbur:pr/1494_ws_dispatch

opened 11:04AM - 21 May 26 UTC

alanbur

+85 -10

Proposed fix for [1494 ws_dispatch() caches external stream fds as the default](…https://github.com/SWI-Prolog/swipl-devel/issues/1494) This PR was heavily AI-assisted as I'm not familiar with the code so I must inject a note of caution. The initial attempt at a fix resulted in a SEGV because as well as stopping caching of external fds, it also changed user_input/console from the old persistent watch path to a temporary add/remove watch path. Testing with my app under `gspy` triggered a SEGV in `el_unwrap()` / `el_end()`, which my app also uses. This was apparently because the GUI debugger/libedit path depends on the old console behaviour. This patch makes `dispatch_fd` explicitly owned, only `pce_dispatch()` can register the console/default input as the persistent dispatch fd. So, In `ws_dispatch()`: * `DEFAULT` and the registered console input use the old persistent `set_watch()` path. * Other concrete streams/fds are watched temporarily for just that one dispatch call. * External fds no longer modify `dispatch_fd`. This removes the old incorrect setting of `dispatch_fd` to any and all fds to just the fd of the console, so (for example) poll ops on a closed fd will no longer fail, whist not changing the existing "This is the default (console) fd" mechanism. I've tested as follows: * The console flood of `Confirmer running; discarding input ...failed` messages is gone. * Tracing with `strace` after socket/HTTP activity no longer shows repeated `POLLNVAL` from a known-closed external fd. * Existing xpce CTest passes: `ctest --test-dir /data2/tmp/swipl-devel-10.1.7/build -R '^xpce:xpce$' --output-on-failure` * A manual test with my app under gspy no longer triggers the `el_unwrap()` / `el_end()` SEGV caused by the first patch attempt. * Pressing keys in the console while the graphical debugger confirmer is active still produces `Confirmer running; discarding input ...ok`, which appears to be existing behaviour for the console/default input.

alanbur · May 21, 2026, 12:13pm

GUI debugger can dispatch events to freed objects during terminal input

opened 12:12PM - 21 May 26 UTC

alanbur

While testing the nfix for SWI-Prolog/swipl-devel#1494 I also saw a separate SEG…V involving the graphical debugger, xpce and terminal input dispatch. I don't think this is caused by the fix for #1494 as this crash happens on a different path - xpce appears to dispatch a queued GUI event to an object that has already been freed while Prolog is blocked reading from `user_input`. The crash is not immediately reproducible. I saw it after using the graphical debugger with `gspy/1`, stepping through code, exiting/re-entering my app REPL a few times, and pressing keys in the terminal while the debugger confirmer was active. Before the SEGV, xpce reported errors such as: ```text ERROR: pce(object) `@(11860891175632)' does not exist (@11860891175632/emacs_editor (freed)) ERROR: In: ERROR: [21] pce_principal:send_class(@(11860891175632),editor,event(@11860893716128/event)) ERROR: [20] pce_principal:send_implementation('emacs_editor->event',event(@11860893716128/event),@(11860891175632)) at .../xpce/prolog/lib/emacs/window.pl:898 ... ``` It then warned about a freed debugger object: ```text [PCE warning: unlink_from: No implementation for: ->input_focus [ 1] M @11860890885552/prolog_debugger (freed) ->input_focus(@off/bool) ] ``` The C stack was: ```text [3] inputFocusFrame() at packages/xpce/src/win/frame.c:1180 [4] pceExecuteGoal() at packages/xpce/src/ker/passing.c:874 [5] vm_send() at packages/xpce/src/ker/passing.c:1166 [6] sendPCE() at packages/xpce/src/ker/passing.c:1478 [7] sdl_frame_event() at packages/xpce/src/sdl/sdlframe.c:711 [8] CtoEvent() at packages/xpce/src/sdl/sdlevent.c:326 [9] ws_dispatch() at packages/xpce/src/sdl/sdlevent.c:820 [10] pceDispatch() at packages/xpce/src/itf/interface.c:635 [11] pce_dispatch() at packages/xpce/swipl/interface.c:2870 [12] PL_dispatch() at src/pl-fli.c:5461 [13] read_char() at packages/libedit/libedit4pl.c:1093 [14] el_wgetc() [15] read_getcmd() [16] el_gets() [17] restore_signals() at packages/libedit/libedit4pl.c:504 [18] S__fillbuf() at src/os/pl-stream.c:695 [20] pl_read_string5_va() at src/pl-string.c:484 ``` The Prolog stack was in my app REPL reading from `user_input`: ```text [18] system:read_string/5 <foreign> [17] read_util:read_line_to_string/2 [16] utils:readLine/3 [15] utils:readLine/2 [14] utils:replLoop/2 [13] utils:repl/2 [12] p2k/0 [11] $toplevel:toplevel_call/1 ``` ChatGPT's analysis is that libedit is blocked reading from `user_input`, calls `PL_dispatch()`, xpce processes a pending SDL frame /editor event and that event targets an `emacs_editor` / `prolog_debugger` object that has already been freed. So this looks like an xpce debugger/event lifetime or reentrancy issue, not an fd-cache issue. That seems plausible but needs confirmation by someone who understands the code. If I see the problem again I'll log more details, but so far it appears to only happen at random.

This was seen during testing of the patch, but I suspect is unrelated.

EricGT · May 21, 2026, 1:21pm

FYI

These GitHub posts that look like they’re from Jan are actually generated by Discourse when someone posts with a link to GitHub.

They confused me at first, because I thought Jan had created them manually.

EricGT · May 21, 2026, 1:27pm

@alanbur

FYI — for SEGVs or other major hard errors, if any output files are generated, such as a crash dump, please pass those along to Jan.

Some AI tools can read and decipher those files almost as easily as plain text. I learned this from experience while working through a SEGV issue a few months ago. I didn’t need to install all the tooling to inspect the files first; I just attached the file with an AI prompt, and it was able to analyze it.

alanbur · May 21, 2026, 1:34pm

I figured that out when the 2nd one arrived

alanbur · May 21, 2026, 1:41pm

I don’t have core dumps enabled, I should probably change that…

Topic		Replies	Views
Ann: SWI-Prolog 9.3.34 Releases	19	345	November 12, 2025
Progressing the SWI-Prolog environment Request For Comments xpce , ide , gui	87	1276	May 7, 2026
Ann: SWI-Prolog 10.0.0 (Stable) Releases	7	2169	December 16, 2025
Ann: SWI-Prolog 9.0.4 (stable) Releases	2	662	May 3, 2023
Ann: SWI-Prolog 9.3.25 Releases	19	407	September 25, 2025

Mute ws_discard_input()

Related topics