Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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
>


      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