# Mute ws\_discard\_input()
**URL:** https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628
**Category:** General
**Tags:** bug
**Created:** [May 18, 2026, 1:35pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628 "2026-05-18T13:35:27Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 18, 2026, 1:35pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/1 "2026-05-18T13:35:27Z")
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](https://swi-prolog.discourse.group/uploads/short-url/oQy4bdkdH5jQRrhdqygwwpONr1a.c) (2.7 KB)
---
### Author:  [@EricGT](https://swi-prolog.discourse.group/u/EricGT)
#### Post date: [May 18, 2026, 1:54pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/2 "2026-05-18T13:54:55Z")
> [@alanbur](#):
>
> Symbitted as `.c` because `.patch` won’t attach.
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.
---
### Author:  [@jan](https://swi-prolog.discourse.group/u/jan)
#### Post date: [May 18, 2026, 2:24pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/3 "2026-05-18T14:24:45Z")
> [@alanbur](#):
>
> 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.
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).
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 18, 2026, 5:13pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/4 "2026-05-18T17:13:13Z")
> [@EricGT](#):
>
> The reason `.patch` files are not allowed here is that the official way to submit changes to the [SWI-Prolog](https://www.swi-prolog.org/pldoc/doc_for?object=manual) codebase is through a Git pull request.
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.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 18, 2026, 5:16pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/5 "2026-05-18T17:16:52Z")
> [@jan](#):
>
> 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).
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?
---
### Author:  [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)
#### Post date: [May 18, 2026, 6:18pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/6 "2026-05-18T18:18:28Z")
> [@alanbur](#):
>
> Submitted as `.c` because `.patch` won’t attach.
Patches can be emailed to [bugs@swi-prolog.org](mailto:bugs@swi-prolog.org) as described in [How to submit patches?](https://www.swi-prolog.org/howto/SubmitPatch.html)
---
### Author:  [@EricGT](https://swi-prolog.discourse.group/u/EricGT)
#### Post date: [May 18, 2026, 6:39pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/7 "2026-05-18T18:39:51Z")
Thanks.
I can add `patch` so those files types can be uploaded in less than a minute. Just need Jan’s approval.
---
### Author:  [@jan](https://swi-prolog.discourse.group/u/jan)
#### Post date: [May 18, 2026, 6:59pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/8 "2026-05-18T18:59:10Z")
The route of choice is GitHub pull requests. If not the result of `git format-patch` sent to [bugs@swi-prolog.org](mailto:bugs@swi-prolog.org). All the rest is emergency only.
---
### Author:  [@jan](https://swi-prolog.discourse.group/u/jan)
#### Post date: [May 18, 2026, 7:00pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/9 "2026-05-18T19:00:52Z")
> [@alanbur](#):
>
> 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?
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?
---
### Author:  [@EricGT](https://swi-prolog.discourse.group/u/EricGT)
#### Post date: [May 18, 2026, 7:03pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/10 "2026-05-18T19:03:51Z")
> [@jan](#):
>
> The route of choice is GitHub pull requests. If not the result of `git format-patch` sent to [bugs@swi-prolog.org](mailto:bugs@swi-prolog.org). All the rest is emergency only.
Per Jan, will **not** be ading `patch` as a file type that can be uploaded here.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 20, 2026, 3:49pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/11 "2026-05-20T15:49:52Z")
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:
```prolog
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.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 20, 2026, 5:31pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/12 "2026-05-20T17:31:05Z")
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:
1. Some socket/HTTP activity uses fd 7.
2. 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.
3. The TCP socket is closed.
4. 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.
5. 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.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 21, 2026, 9:33am UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/13 "2026-05-21T09:33:12Z")
Bug logged, PR to follow:
>
>
> 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.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 21, 2026, 11:11am UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/14 "2026-05-21T11:11:29Z")
As I note in the PR, this was heavily AI-assisted - caveat emptor…
>
>
> 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.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 21, 2026, 12:13pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/15 "2026-05-21T12:13:58Z")
See also:
>
>
> 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 \
> \[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.
---
### Author:  [@EricGT](https://swi-prolog.discourse.group/u/EricGT)
#### Post date: [May 21, 2026, 1:21pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/16 "2026-05-21T13:21:14Z")
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.
---
### Author:  [@EricGT](https://swi-prolog.discourse.group/u/EricGT)
#### Post date: [May 21, 2026, 1:27pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/17 "2026-05-21T13:27:15Z")
@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.
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 21, 2026, 1:34pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/18 "2026-05-21T13:34:54Z")
I figured that out when the 2nd one arrived 😆
---
### Author:  [@alanbur](https://swi-prolog.discourse.group/u/alanbur)
#### Post date: [May 21, 2026, 1:41pm UTC](https://swi-prolog.discourse.group/t/mute-ws-discard-input/9628/19 "2026-05-21T13:41:46Z")
I don’t have core dumps enabled, I should probably change that…