Inspecting memory address contents in GDB

Inspecting memory address contents in GDB

[Jonny Grant]

Hi
Pasting some output lines from a core dump gdb session below.
I noticed after "x/8c" the line seems stuck in ASCII mode. So when I do "x/8b" it doesn't go back to output in hex, is that expected?

It goes back to hex after I used the command "x /8xb"

~$ gdb --version
GNU gdb (Ubuntu 12.1-3ubuntu2) 12.1

(gdb) x/8b 0x000044d1bd2827c1
0x44d1bd2827c1:	0x0f	0x0b	0xcc	0xcc	0xcc	0xcc	0xcc	0xcc
(gdb) x/8c 0x000044d1bd2827c1
0x44d1bd2827c1:	15 '\017'	11 '\v'	-52 '\314'	-52 '\314'	-52 '\314'	-52 '\314'	-52 '\314'	-52 '\314'
(gdb) x/8b 0x000044d1bd2827c1
0x44d1bd2827c1:	15 '\017'	11 '\v'	-52 '\314'	-52 '\314'	-52 '\314'	-52 '\314'	-52 '\314'	-52 '\314'
(gdb) x /8xb 0x000044d1bd2827c1
0x44d1bd2827c1:	0x0f	0x0b	0xcc	0xcc	0xcc	0xcc	0xcc	0xcc

I know the values turned out to not be ASCII in this case.

Kind regards, Jonny

Re: Inspecting memory address contents in GDB

[Andreas Schwab]

On Apr 09 2023, Jonny Grant wrote:

> Hi
> Pasting some output lines from a core dump gdb session below.
> I noticed after "x/8c" the line seems stuck in ASCII mode. So when I do "x/8b" it doesn't go back to output in hex, is that expected?

From help x:

    Defaults for format and size letters are those previously used.
    Default count is 1.  Default address is following last thing printed
    with this command or "print".

'c' is a format, 'b' is a size letter.  Each one will independently
remain in effect until a different format and size, resp., is used.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Inspecting memory address contents in GDB

[Jonny Grant]

On 09/04/2023 20:50, Andreas Schwab wrote:
> On Apr 09 2023, Jonny Grant wrote:
> 
>> Hi
>> Pasting some output lines from a core dump gdb session below.
>> I noticed after "x/8c" the line seems stuck in ASCII mode. So when I do "x/8b" it doesn't go back to output in hex, is that expected?
> 
>>From help x:
> 
>     Defaults for format and size letters are those previously used.
>     Default count is 1.  Default address is following last thing printed
>     with this command or "print".
> 
> 'c' is a format, 'b' is a size letter.  Each one will independently
> remain in effect until a different format and size, resp., is used.
> 

Many thanks Andreas, that makes sense.

I tried to make a dump, but got arguments wrong, gdb core dumped itself. (feels like the macro inhibited the prompt). It says to file as a gdb bug 

Regards, Jonny


$ gdb -c crash2_S11_1681076589.core
GNU gdb (Ubuntu 12.1-3ubuntu2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 830133]

This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.ubuntu.com 
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
Core was generated by `./crash2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000562e40e0b13d in ?? ()
(gdb) define mem_dump
Type commands for definition of "mem_dump".
End with a line saying just "end".
>dump binary memory dump.bin $arg0 $arg0+$arg1
>end
(gdb) mem_dump 100 0x0000562e40e0b13d
/build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712: internal-error: virtual memory exhausted: can't allocate 94756656951613 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x559d96041fb6 ???
0x559d963a08b4 ???
0x559d963a0af0 ???
0x559d964efef4 ???
0x559d9639be91 ???
0x559d964f3c4a ???
0x559d9607b044 ???
0x559d96077714 ???
0x559d963611ef ???
0x559d96083bb2 ???
0x559d96083ff9 ???
0x559d96084365 ???
0x559d9636104d ???
0x559d96141c64 ???
0x559d96141ff0 ???
0x559d961426a2 ???
0x7f306352374c ???
0x559d961427fd ???
0x559d961429b3 ???
0x559d96140b4c ???
0x559d964f04a5 ???
0x559d964f0a66 ???
0x559d961fb66c ???
0x559d961fd3a4 ???
0x559d95fa49bd ???
0x7f306222350f __libc_start_call_main
	../sysdeps/nptl/libc_start_call_main.h:58
0x7f30622235c8 __libc_start_main_impl
	../csu/libc-start.c:381
0x559d95faa524 ???
0xffffffffffffffff ???
---------------------
/build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712: internal-error: virtual memory exhausted: can't allocate 94756656951613 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/build/gdb-hsz3w3/gdb-12.1/gdb/utils.c:712: internal-error: virtual memory exhausted: can't allocate 94756656951613 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
Aborted (core dumped)