From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id E28613858D28 for ; Sun, 9 Apr 2023 22:03:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E28613858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wm1-x333.google.com with SMTP id hg25-20020a05600c539900b003f05a99a841so9786005wmb.3 for ; Sun, 09 Apr 2023 15:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; t=1681077798; x=1683669798; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=ddKqmgbewMqGoGl9YnlU7nr/mKfLFXP07Sfoi8HS0wo=; b=Jj4tTTmoB8Zf1ydJKBPQ36BnVn3Y8sh0rLJY037sMHQsnC616zQOcNy48Mv41waX73 iHj8l8KIpZjA0Hy8qRSae9bWh7at5Fw58oBFMIZn7i3rGsFWBtQrSP6XB/qF/oJkGyaG Vxpd0oHx5Y0d8hYDvcqg3l72T21cAEMiNmZC0rmTWZUOcvLWrBW3Fy2KG86mfMP1jcd7 vg+zmGTGr7g9gArndVY9qqPsLk0X66m0NXjUMPsvzYSobAlLqd1SIbTt34mDEcbwkg74 alkDOE53tgmEZPertpevjDVsRN2FigHqGWQFDD98OjzqWxXbcP/pTv3xRAu4ambKjC7A 3r7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681077798; x=1683669798; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ddKqmgbewMqGoGl9YnlU7nr/mKfLFXP07Sfoi8HS0wo=; b=y1MJ83GwIcbnwDKiJSuBpoLxkbHij+gAo7TNNU9/U0BDaHK01/PGuyiKSTwd8NEQ1X gNjXPJAnxx1l4crGemQxam/UHsYchhjcgYDqfmtc60at9Hk+JEkLyEqFFjZCHmmF8fUE /XGATsmz7+/i6gWsBBcVcYutx5XhJfAJeMFfKkA05kbXoQNzn5ie9dYaLmAxLFX8vXlP OVWrB6DF5be/nVz7vQ7Qg0ETiZ0u+WUtN/YWmfYKs5K6HKuvmheiAZj9B/HPzH+OTYIM Nll0nFAkGBAxhHMtqLXxpl2HjHnDe00+GdQhTcHCfanH3aMjgyNQ/O08CyxIC6NzwZYF q8HA== X-Gm-Message-State: AAQBX9elvlkC+Jxx8L3i5fuooRdetpyXb2MzTTAHls0UA5NrgeoBLRfU 6/gpYkoDyal5hNm/+lcbdU1dt3jM7Leqrvd/OV8= X-Google-Smtp-Source: AKy350YpXMxBvNsZ0r2ZbXKkj04JsAXvC40sDoPeNH+S68mMNbeqHrAs+0OhvPo26mdrgnHw5w5TjA== X-Received: by 2002:a7b:c40f:0:b0:3ee:8a51:d252 with SMTP id k15-20020a7bc40f000000b003ee8a51d252mr6106289wmi.32.1681077797952; Sun, 09 Apr 2023 15:03:17 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id l13-20020a1c790d000000b003f071466229sm11247482wme.17.2023.04.09.15.03.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Apr 2023 15:03:17 -0700 (PDT) Message-ID: <6ebd87ef-bf5f-73c6-27f1-9c915eb08abe@jguk.org> Date: Sun, 9 Apr 2023 23:03:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 From: Jonny Grant Subject: Re: Inspecting memory address contents in GDB To: Andreas Schwab Cc: gdb@sourceware.org References: <87y1n0sum1.fsf@igel.home> Content-Language: en-GB In-Reply-To: <87y1n0sum1.fsf@igel.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 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: . Find the GDB manual and other documentation resources online at: . 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: . /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)