How to Print the Full Value of a Long C String in GDB

By the end of this page, you will understand why GDB shortens long string output, how to change that behavior, and which commands to use to print complete C strings while debugging. You will also learn when to use temporary vs persistent settings and how this fits into real debugging workflows.

When GDB prints variables, it tries to keep output manageable. For long arrays, long strings, and large data structures, it often truncates the displayed value so your terminal does not get flooded with data.

For C strings, this usually means GDB shows only the first part of the string followed by ....

The core concept is that GDB's printing behavior is configurable. You can tell GDB to:

• print more characters
• remove the limit entirely
• inspect memory in different ways when needed

This matters in real programming because long strings often contain useful debugging information, such as:

• file paths
• SQL queries
• HTTP requests
• JSON payloads
• error messages
• generated text

If GDB truncates the string, you may miss the exact bug. For example, the difference between a correct and broken path might be near the end of the string.

In GDB, the most common setting for this is:

set print elements 0

Setting print elements to 0 means do not limit the number of elements printed. For a C string, that allows GDB to print the full null-terminated string instead of abbreviating it.

You can then print the variable normally with:

print my_string

or:

p my_string

This is the main solution to the question.

Think of GDB like a document preview tool.

• By default, it shows only the beginning of a long document so the screen stays readable.
• The actual document is still there.
• You must change the preview settings if you want to see the whole thing.

So a long C string is like a long paragraph in a preview window:

• default behavior: show the first part
• adjusted setting: show the entire paragraph

set print elements 0 is like telling the preview tool: stop shortening the content.

The key GDB command is:

set print elements 0

Then print the string:

print message

Example C program

#include <stdio.h>

int main(void) {
    const char *message = "This is a very long string that GDB may abbreviate by default when printing, especially if your print settings limit how many elements are shown.";
    printf("Ready to debug\n");
    return 0;
}

Example GDB session

(gdb) break main
(gdb) run
(gdb) next
(gdb) print message
$1 = 0x402004 "This is a very long string that GDB may abbreviate ..."

(gdb) set print elements 0
(gdb) print message
$2 = 0x402004 "This is a very long string that GDB may abbreviate by default when printing, especially if your print settings limit how many elements are shown."

Set a specific limit instead of unlimited

If you do not want unlimited output, use a number:

set print elements 200

This tells GDB to print up to 200 elements or characters.

Useful related command

Consider this program:

#include <stdio.h>

int main(void) {
    const char *name = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-long-debug-string-example";
    return 0;
}

Now imagine this GDB session:

(gdb) break main
(gdb) run
(gdb) next
(gdb) print name

What happens step by step

1. break main

   • GDB sets a breakpoint at the start of main.

2. run

   • The program starts and pauses at main.

3. next

   • GDB executes the current line so name is initialized.

4. print name

Printing full strings in GDB is useful in many practical debugging situations:

• Debugging file paths

  • A path may look correct at the beginning but contain a wrong directory or hidden suffix at the end.

• Inspecting HTTP requests or responses

  • Long headers, JSON bodies, or query strings are often truncated unless you change print settings.

• Checking SQL queries

  • Dynamically built SQL strings can fail because of a typo near the end.

• Analyzing log messages

  • Error messages may include detailed context that gets cut off.

• Verifying generated text

  • Code generators, serializers, or template systems often produce long output strings.

• Debugging command-line tools

  • Full command strings and arguments may be long and need to be inspected exactly as built.

In real projects, developers usually combine full-string printing with a few common debugging habits.

1. Temporary debugging configuration

During a debugging session, a developer may run:

set print elements 0

This is useful when investigating one bug without permanently changing all GDB behavior.

2. Persistent configuration

If full output is often needed, developers may place GDB settings in a personal GDB init file so common print preferences are loaded automatically.

3. Guarding against invalid strings

If a pointer might be NULL or invalid, developers often inspect it carefully before treating it as a C string.

Example pattern in C:

if (message == NULL) {
    fprintf(stderr, "message is NULL\n");
    return 1;
}

Then in GDB, printing the pointer becomes safer and easier to interpret.

4. Using memory views for raw inspection

If a string is corrupted, not null-terminated, or stored in a buffer with binary data, developers often switch from print to memory examination commands.

For example:

x/s message

This prints memory at as a string.

Here are some common beginner mistakes when trying to print full strings in GDB.

1. Forgetting that GDB has a print limit

Beginners often assume the string itself is incomplete.

Broken assumption:

(gdb) print message
$1 = "hello world ..."

This does not necessarily mean the string in memory is truncated. It may only be the display output.

Avoid it by checking:

show print elements

and then setting:

set print elements 0

2. Printing before the variable is initialized

Broken C example:

const char *msg;
return 0;

If you stop before assignment and print msg, the value may be garbage or NULL.

Avoid it by stepping to the line after initialization.

3. Confusing a pointer with the pointed-to data

For a char *, GDB usually shows both the address and the string, but understanding the difference matters.

Example:

Here are the most relevant ways to inspect string data in GDB.

# Show current print limit
show print elements

# Print all elements with no limit
set print elements 0

# Print up to a fixed number of elements
set print elements 200

# Print a variable
print my_string
p my_string

# Print memory at an address as a C string
x/s my_string

# Inspect raw bytes
x/64bx my_string

Key rule

For long C strings in GDB, the usual fix is:

set print elements 0

Remember

• C strings must be null-terminated.
• Truncated output does not always mean truncated data.
• print respects GDB print settings.
• x/s is useful for viewing memory directly as a string.

Why does GDB shorten long strings by default?

GDB limits output to keep debugging sessions readable and to avoid printing huge amounts of data automatically.

What command prints the full string in GDB?

Use:

set print elements 0

Then print the variable normally.

Does set print elements 0 affect only strings?

No. It affects how many elements GDB prints for arrays and similar values in general.

How can I check the current print limit in GDB?

Use:

show print elements

What if print still does not show what I expect?

Try:

x/s my_string

If the data is corrupted or not null-terminated, inspect raw bytes with x/nbx.

Can I set a limit instead of printing everything?

Yes. For example:

set print elements 200

What happens if the buffer is not a valid C string?

GDB may read past the intended buffer until it finds a null byte. In that case, inspect the memory manually and verify the buffer contents.

• C strings — GDB printing depends on how null-terminated strings work in C.
• Pointers in C — String variables are often char *, so pointer basics are essential.
• Arrays in C — GDB uses similar element-printing rules for arrays and strings.
• Memory inspection in GDB — Commands like x/s and x/64bx are closely related tools.
• Null termination — A C string must end with \0 for correct printing and processing.
• Debugging with breakpoints — You usually inspect strings after pausing execution at the right place.
• Buffer overflows — Corrupted strings often come from writing past buffer boundaries.