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:
: 27612 (view as bug list)
Depends on: 27910
Blocks:
  Show dependency treegraph
 
Reported: 2023-08-31 16:22 UTC by jaeckel
Modified: 2026-01-25 17:41 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:


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.
Comment 2 Tom de Vries 2025-03-04 14:43:29 UTC
I've managed to reproduce with gdb as ncurses app.

Terminal 1:
...
$ gdbserver localhost:2345 gdb -tui
Process gdb created; pid = 18849
Listening on port 2345
...

Terminal 2:
...
$ gdb -ex "target remote localhost:2345"
   ...
0x00007ffff7fe4f00 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) continue
...

Terminal 1: Check for presence of TUI window

Terminal 2: Press ^C, and:
...
(gdb) detach
Detaching from program: target:/usr/bin/gdb, process 18849
Ending remote debugging.
[Inferior 1 (process 18849) detached]
(gdb) 
...

Terminal 1: Observe "Detaching from process 18849" in TUI command window:
...
┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                             │
│                                                                             │
│                                                                             │
│                                                                             │
│                                                                             │
│              [ No Source Available ]                                        │
│                                                                             │
│                                                                             │
│                                                                             │
│                                                                             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘
None No process In:                                               L??   PC: ?? 
(gdb) Detaching from process 18849









...
Comment 3 Tom de Vries 2025-03-04 14:59:37 UTC
(In reply to jaeckel from comment #0)
> Still the patch is not
> complete as described in the commit message

That's:
...
This patch is not completely functional, as the file somehow doesn't get
updated until the debugging session is finished, even though the `FILE*`
gets `fflush()`'ed.
...

I can't reproduce this with the scenario in comment 2, but perhaps that's because the detach that generates the message also finishes the debug session.
Comment 4 Tom Tromey 2026-01-25 17:41:04 UTC
*** Bug 27612 has been marked as a duplicate of this bug. ***