From: Hui Zhu <teawater@gmail.com>
To: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Cc: Michael Snyder <msnyder@vmware.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Quit after debugging corefiles
Date: Wed, 23 Jun 2010 02:53:00 -0000 [thread overview]
Message-ID: <AANLkTilv4K14M4ZP6at_xbENQm7qOUaA6oF6Nh-SYuYD@mail.gmail.com> (raw)
In-Reply-To: <4C211717.60505@linux.vnet.ibm.com>
I reproduce this issue too.
Thanks,
Hui
On Wed, Jun 23, 2010 at 04:03, Edjunior Barbosa Machado
<emachado@linux.vnet.ibm.com> wrote:
>
>
> On 06/22/2010 02:42 PM, Michael Snyder wrote:
>>
>> Hmm, I don't think you're supposed to "continue" when debugging a core
>> file...
>
> I meant I had already started debugging (with breakpoints and 'run') before,
> which is permitted in the current version (although I noticed this behavior
> has been discussed in the thread that Pedro previously mentioned).
>
> You can see the full output below. Sorry if it was unclear in the beginning.
>
> Using the following faulty code:
>
> $ cat -n corefile-quit.c
> 1 #include <stdio.h>
> 2
> 3 static void
> 4 fault_func (char *arg)
> 5 {
> 6 *arg = 0; /* segfault */
> 7 }
> 8
> 9 int main (int argc, char *argv[])
> 10 {
> 11 char *ptr = NULL;
> 12
> 13 printf("hello world\n");
> 14
> 15 fault_func (ptr);
> 16
> 17 return 0;
> 18 }
>
> $ ./gdb -q ./corefile-quit core
> Reading symbols from
> /home/emachado/work/gdb/community/build/gdb/corefile-quit...done.
> [New Thread 17524]
>
> warning: Can't read pathname for load map: Input/output error.
> Reading symbols from /lib/i686/cmov/libc.so.6...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/i686/cmov/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/ld-linux.so.2
> Core was generated by `./corefile-quit'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x080483ca in fault_func (arg=0x0) at corefile-quit.c:6
> 6 *arg = 0; /* segfault */
> Setting up the environment for debugging gdb.
> Function "internal_error" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) [answered
> N; input not from terminal]
> Function "info_command" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) [answered
> N; input not from terminal]
> .gdbinit:8: Error in sourced command file:
> Argument required (one or more breakpoint numbers).
> (gdb) b 14
> Breakpoint 1 at 0x80483ec: file corefile-quit.c, line 14.
> (gdb) r
> Starting program: /home/emachado/work/gdb/community/build/gdb/corefile-quit
> hello world
>
> Breakpoint 1, main (argc=
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> eax) at 0x80483d2.
> 1, argv=0xbffff544) at corefile-quit.c:15
> 15 fault_func (ptr);
> (gdb) set ptr="new"
> (gdb) cont
> Continuing.
>
> Program exited normally.
> (gdb) quit
> ../../git/gdb/inferior.c:362: internal-error: find_inferior_pid: Assertion
> `pid != 0' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) n
> ../../git/gdb/inferior.c:362: internal-error: find_inferior_pid: Assertion
> `pid != 0' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) n
>
> --
> Edjunior Barbosa Machado
> IBM Linux Technology Center
>
prev parent reply other threads:[~2010-06-23 2:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 13:18 Edjunior Barbosa Machado
2010-06-22 13:22 ` Pedro Alves
2010-06-22 17:42 ` Michael Snyder
2010-06-22 20:03 ` Edjunior Barbosa Machado
2010-06-23 2:53 ` Hui Zhu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTilv4K14M4ZP6at_xbENQm7qOUaA6oF6Nh-SYuYD@mail.gmail.com \
--to=teawater@gmail.com \
--cc=emachado@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox