Introduction

If GDB keeps printing New Thread and Thread exited messages while you debug a multithreaded program, the setting you want is print thread-events. Turning it off removes those lifecycle notices without disabling thread debugging itself. That is usually the cleanest way to make a busy debugging session readable again.

The Command You Need

Inside GDB, run:

set print thread-events off

After that, GDB stops showing the automatic notifications when threads start or exit.

You can confirm the current value with:

show print thread-events

If you want the messages back later in the same session, turn them on again:

set print thread-events on

Why This Works

Thread lifecycle messages are part of GDB's informational output, not part of your program's own stdout or stderr. They are controlled by a debugger setting specifically for thread event reporting. Disabling the setting does not prevent GDB from tracking threads internally. Breakpoints, thread switching, backtraces, and inspection commands still work normally.

That distinction matters. You are muting a noisy status message, not disabling thread-awareness.

Make the Change Permanent

If you always want quieter multithreaded sessions, add the command to your ~/.gdbinit file:

set print thread-events off

Then every new GDB session started under that user account will inherit the setting.

If you prefer to keep your global defaults unchanged, you can also place the command in a project-local .gdbinit if your setup allows it. That is useful when only one particular service or test binary creates a large amount of thread churn.

Example Workflow

Suppose you are debugging a program that creates worker threads dynamically. A typical session might look like this:

1gdb ./my_server
2(gdb) set print thread-events off
3(gdb) run
4(gdb) info threads
5(gdb) thread 3
6(gdb) bt

You still have full visibility into the threads you care about. The only thing missing is the stream of automatic "thread created" and "thread exited" lines.

This is especially helpful when:

• your application uses thread pools
• libraries create helper threads in the background
• you are capturing debugger output in logs
• thread lifecycle messages are burying breakpoint output

Related Noise Controls

If the session is still too noisy after suppressing thread events, remember that the source may be something else:

• your program's own logging
• inferior stdout or stderr
• breakpoint command output
• shared-library load messages

The thread-event setting only affects the specific New Thread and Thread exited notices. If you still see lots of output, identify which system is printing it before changing more settings.

For example, shared-library notifications are controlled separately:

set print symbol-loading off

That is not a replacement for thread-events, but it helps illustrate that GDB splits different categories of verbosity into separate controls.

Common Pitfalls

The most common pitfall is trying shell redirection or terminal filtering to hide the messages. That approach hides useful output along with the noisy lines and is harder to reverse than using the dedicated GDB setting.

Another pitfall is assuming that turning thread events off will break thread debugging. It does not. GDB still knows about threads; it simply stops announcing every creation and exit.

Developers also put the command in .gdbinit and forget they did so, then later wonder why thread notifications never appear. If that happens, use show print thread-events at the start of the session.

Finally, if the output is coming from your runtime or your application logs rather than from GDB itself, set print thread-events off will not help. Make sure the noisy lines are truly debugger messages.

Summary

• Use set print thread-events off to suppress New Thread and Thread exited messages.
• The setting affects only debugger status output, not actual thread debugging capability.
• Use show print thread-events to verify the current state.
• Add the command to ~/.gdbinit if you want the behavior every time.
• If noise remains, confirm whether it is really coming from GDB or from the program being debugged.