This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: "finish" command leads to SIGTRAP
- From: David Griffiths <dgriffiths at undo dot io>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 21 Feb 2019 12:16:43 +0000
- Subject: Re: "finish" command leads to SIGTRAP
- References: <CA++j6c7bhP7=AWWdzBajC7KUah1gwj25-Bpoqd1-Xs_67z5kVw@mail.gmail.com> <b437759f-5223-fcd2-1e68-f77051a2f910@redhat.com> <CA++j6c4co2Uz=3q952pf3skq8xMdsmQ_4+H6eMBkAdvyXMzK8A@mail.gmail.com>
Oh, I should add a bit extra to the end because in the good case it is also
doing the PTRACE_CONT:
> LLR: Preparing to resume Thread 0x7ffff7fd8700 (LWP 12901), 0,
inferior_ptid Thread 0x7ffff7fd8700 (LWP 12901)
> LLR: PTRACE_CONT Thread 0x7ffff7fd8700 (LWP 12901), 0 (resume event
thread)
> infrun: prepare_to_wait
> linux_nat_wait: [process -1], [TARGET_WNOHANG]
> RSRL: NOT resuming LWP Thread 0x7ffff7fd8700 (LWP 12901), not stopped
> LLW: enter
> LNW: waitpid(-1, ...) returned 0, ERRNO-OK
> RSRL: NOT resuming LWP Thread 0x7ffff7fd8700 (LWP 12901), not stopped
> LLW: exit (ignore)
etc
On Thu, 21 Feb 2019 at 12:13, David Griffiths <dgriffiths@undo.io> wrote:
> Ok thanks, did that. If I compare the output for the bad case with the
> good case, this seems to be the main difference:
>
> < infrun: proceed: resuming Thread 0x7ffff7fd8700 (LWP 12901)
> < infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current
> thread [Thread 0x7ffff7fd8700 (LWP 12901)] at 0x7ffff6d33b00
> < LLR: Preparing to resume Thread 0x7ffff7fd8700 (LWP 12901), 0,
> inferior_ptid Thread 0x7ffff7fd8700 (LWP 12901)
> < LLR: PTRACE_CONT Thread 0x7ffff7fd8700 (LWP 12901), 0 (resume event
> thread)
> ---
> > infrun: step-over queue now empty
> > infrun: resuming [Thread 0x7ffff7fd8700 (LWP 12901)] for step-over
> > infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current
> thread [Thread 0x7ffff7fd8700 (LWP 12901)] at 0x7ffff6d33b00
> > LLR: Preparing to step Thread 0x7ffff7fd8700 (LWP 12901), 0,
> inferior_ptid Thread 0x7ffff7fd8700 (LWP 12901)
> > LLR: PTRACE_SINGLESTEP Thread 0x7ffff7fd8700 (LWP 12901), 0 (resume
> event thread)
> 10a11
> > infrun: proceed: [Thread 0x7ffff7fd8700 (LWP 12901)] resumed
> 27c28,60
> < infrun: random signal (GDB_SIGNAL_TRAP)
> ---
> > infrun: no stepping, continue
> > infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current
> thread [Thread 0x7ffff7fd8700 (LWP 12901)] at 0x7ffff6d33b01
>
> Cheers,
>
> David
>
> On Thu, 21 Feb 2019 at 11:24, Pedro Alves <palves@redhat.com> wrote:
>
>> On 02/21/2019 11:21 AM, David Griffiths wrote:
>> >
>> > I need it to work because I'm trying to automate something via gdb/MI.
>> Any
>> > suggestions as to how to debug this would be very welcome.
>>
>> Start with "set debug infrun 1".
>>
>> And then "set debug lin-lwp 1" if debugging natively, or
>> "set debug remote 1" if using the remote serial protocol.
>>
>> Thanks,
>> Pedro Alves
>>
>
>
> --
>
> David Griffiths, Senior Software Engineer
>
> Undo <https://undo.io> | Resolve even the most challenging software
> defects with software flight recorder technology
>
> Software reliability report: optimizing the software supplier and customer
> relationship
> <https://info.undo.io/software-reliability-report-optimizing-supplier-and-customer-relationship>
>
--
David Griffiths, Senior Software Engineer
Undo <https://undo.io> | Resolve even the most challenging software defects
with software flight recorder technology
Software reliability report: optimizing the software supplier and customer
relationship
<https://info.undo.io/software-reliability-report-optimizing-supplier-and-customer-relationship>