Bug 30815 - gdbserver prints debug info unconditionally to stderr
Summary: gdbserver prints debug info unconditionally to stderr
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: server (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-31 16:22 UTC by jaeckel
Modified: 2023-09-01 12:43 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
A WIP patch to approach the issue. (2.95 KB, patch)
2023-08-31 16:22 UTC, jaeckel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jaeckel 2023-08-31 16:22:58 UTC
Created attachment 15097 [details]
A WIP patch to approach the issue.

When debugging an ncurses application that is using other background processes/threads (like e.g. `profanity` https://profanity-im.github.io/), `gdbserver` prints `Detaching from process XYZ` directly to stderr after `profanity` started one of those processes.

This leads to the ncurses window being modified and those debug statements being printed somewhere on the screen.

Reproducing is possible with e.g. profanity.

1. start profanity in gdbserver

```
$ gdbserver localhost:1234 profanity
```

2. connect to said gdbserver instance in another terminal

```
$ gdb -ex "target remote localhost:1234" -ex continue
```

3. connect with profanity to an xmpp server

```
/connect <jid>
```

Now you will see multiple `Detaching from process XYZ` messages throughout the window.

I've been able to reproduce some artifacts with `irssi` as well, but it's not that obvious as with `profanity`.

The patchfile that I've attached solves my initial problem, those messages aren't printed in the debugged window anymore. Still the patch is not complete as described in the commit message and I didn't want to invest more time before I've got the OK that this could be an acceptable solution.
Comment 1 Tom Tromey 2023-09-01 12:43:20 UTC
Another option might be to send this back to gdb in "O" packets.
However, this won't work with non-stop.