help with loading core files

help with loading core files

[Mathew Yeates]

Hi
I posted something about this earlier and I now have time to try and
figure this out.
When I run gdb myexe mycore
I get
Program terminated with signal 5, Trace/breakpoint trap.

This is gdb-7.2.50.20100713.

Any ideas for me to try? I'm no gdb guru but maybe I can generate info
usable  to someone.

Mathew

Re: help with loading core files

[Michael Snyder]

Mathew Yeates wrote:
> Hi
> I posted something about this earlier and I now have time to try and
> figure this out.
> When I run gdb myexe mycore
> I get
> Program terminated with signal 5, Trace/breakpoint trap.
> 
> This is gdb-7.2.50.20100713.
> 
> Any ideas for me to try? I'm no gdb guru but maybe I can generate info
> usable  to someone.
> 
> Mathew

What signal do you believe your corefile should be reporting?

What host and operating system are you running on?

Re: help with loading core files

[Mathew Yeates]

I'm not sure about your first question.
1) I run my program in the debugger and go to a particular line
2) I generate a core file with generate-core-file
3) I exit gdb
4) I run gdb myexecutable mycorefile

Shouldn't I be able to continue my program from here? Instead, I get
"Program terminated with signal 5, Trace/breakpoint trap"
And I can't continue because I get
"The program is not being run."

 x86_64 x86_64 x86_64 GNU/Linux


On Thu, Jul 22, 2010 at 10:07 AM, Michael Snyder <msnyder@vmware.com> wrote:
> Mathew Yeates wrote:
>>
>> Hi
>> I posted something about this earlier and I now have time to try and
>> figure this out.
>> When I run gdb myexe mycore
>> I get
>> Program terminated with signal 5, Trace/breakpoint trap.
>>
>> This is gdb-7.2.50.20100713.
>>
>> Any ideas for me to try? I'm no gdb guru but maybe I can generate info
>> usable  to someone.
>>
>> Mathew
>
> What signal do you believe your corefile should be reporting?
>
> What host and operating system are you running on?
>

Re: help with loading core files

[Michael Snyder]

Mathew Yeates wrote:
> I'm not sure about your first question.
> 1) I run my program in the debugger and go to a particular line
> 2) I generate a core file with generate-core-file
> 3) I exit gdb
> 4) I run gdb myexecutable mycorefile

Oh, ok, then signal 5 is the correct signal.

> Shouldn't I be able to continue my program from here? Instead, I get
> "Program terminated with signal 5, Trace/breakpoint trap"
> And I can't continue because I get
> "The program is not being run."

No, you can't resume running from a corefile.

>  x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> On Thu, Jul 22, 2010 at 10:07 AM, Michael Snyder <msnyder@vmware.com> wrote:
>> Mathew Yeates wrote:
>>> Hi
>>> I posted something about this earlier and I now have time to try and
>>> figure this out.
>>> When I run gdb myexe mycore
>>> I get
>>> Program terminated with signal 5, Trace/breakpoint trap.
>>>
>>> This is gdb-7.2.50.20100713.
>>>
>>> Any ideas for me to try? I'm no gdb guru but maybe I can generate info
>>> usable  to someone.
>>>
>>> Mathew
>> What signal do you believe your corefile should be reporting?
>>
>> What host and operating system are you running on?
>>

Re: help with loading core files

[Mathew Yeates]

bummer. Is there any way to do this? I assumed that the core file
contained enough information to resume processing.


>
>> Shouldn't I be able to continue my program from here? Instead, I get
>> "Program terminated with signal 5, Trace/breakpoint trap"
>> And I can't continue because I get
>> "The program is not being run."
>
> No, you can't resume running from a corefile.
>
>>  x86_64 x86_64 x86_64 GNU/Linux
>>
>>
>> On Thu, Jul 22, 2010 at 10:07 AM, Michael Snyder <msnyder@vmware.com>
>> wrote:
>>>
>>> Mathew Yeates wrote:
>>>>
>>>> Hi
>>>> I posted something about this earlier and I now have time to try and
>>>> figure this out.
>>>> When I run gdb myexe mycore
>>>> I get
>>>> Program terminated with signal 5, Trace/breakpoint trap.
>>>>
>>>> This is gdb-7.2.50.20100713.
>>>>
>>>> Any ideas for me to try? I'm no gdb guru but maybe I can generate info
>>>> usable  to someone.
>>>>
>>>> Mathew
>>>
>>> What signal do you believe your corefile should be reporting?
>>>
>>> What host and operating system are you running on?
>>>
>
>

Re: help with loading core files

[Michael Snyder]

None that I'm aware of, at least on Linux.

Mathew Yeates wrote:
> bummer. Is there any way to do this? I assumed that the core file
> contained enough information to resume processing.
> 
> 
>>> Shouldn't I be able to continue my program from here? Instead, I get
>>> "Program terminated with signal 5, Trace/breakpoint trap"
>>> And I can't continue because I get
>>> "The program is not being run."
>> No, you can't resume running from a corefile.
>>
>>>  x86_64 x86_64 x86_64 GNU/Linux
>>>
>>>
>>> On Thu, Jul 22, 2010 at 10:07 AM, Michael Snyder <msnyder@vmware.com>
>>> wrote:
>>>> Mathew Yeates wrote:
>>>>> Hi
>>>>> I posted something about this earlier and I now have time to try and
>>>>> figure this out.
>>>>> When I run gdb myexe mycore
>>>>> I get
>>>>> Program terminated with signal 5, Trace/breakpoint trap.
>>>>>
>>>>> This is gdb-7.2.50.20100713.
>>>>>
>>>>> Any ideas for me to try? I'm no gdb guru but maybe I can generate info
>>>>> usable  to someone.
>>>>>
>>>>> Mathew
>>>> What signal do you believe your corefile should be reporting?
>>>>
>>>> What host and operating system are you running on?
>>>>
>>

Re: help with loading core files

[Mathew Yeates]

How do people deal with running to a breakpoint that takes 10 minutes
to get to? It would be great if I could run to the breakpoint once,
save some info, and in the future just return to the breakpoint and
keep running from there.

On Thu, Jul 22, 2010 at 10:29 AM, Michael Snyder <msnyder@vmware.com> wrote:
> None that I'm aware of, at least on Linux.
>
> Mathew Yeates wrote:
>>
>> bummer. Is there any way to do this? I assumed that the core file
>> contained enough information to resume processing.
>>
>>
>>>> Shouldn't I be able to continue my program from here? Instead, I get
>>>> "Program terminated with signal 5, Trace/breakpoint trap"
>>>> And I can't continue because I get
>>>> "The program is not being run."
>>>
>>> No, you can't resume running from a corefile.
>>>
>>>>  x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>>
>>>> On Thu, Jul 22, 2010 at 10:07 AM, Michael Snyder <msnyder@vmware.com>
>>>> wrote:
>>>>>
>>>>> Mathew Yeates wrote:
>>>>>>
>>>>>> Hi
>>>>>> I posted something about this earlier and I now have time to try and
>>>>>> figure this out.
>>>>>> When I run gdb myexe mycore
>>>>>> I get
>>>>>> Program terminated with signal 5, Trace/breakpoint trap.
>>>>>>
>>>>>> This is gdb-7.2.50.20100713.
>>>>>>
>>>>>> Any ideas for me to try? I'm no gdb guru but maybe I can generate info
>>>>>> usable  to someone.
>>>>>>
>>>>>> Mathew
>>>>>
>>>>> What signal do you believe your corefile should be reporting?
>>>>>
>>>>> What host and operating system are you running on?
>>>>>
>>>
>
>

Re: help with loading core files

[Jan Kratochvil]

On Thu, 22 Jul 2010 19:55:03 +0200, Mathew Yeates wrote:
> How do people deal with running to a breakpoint that takes 10 minutes
> to get to? It would be great if I could run to the breakpoint once,
> save some info, and in the future just return to the breakpoint and
> keep running from there.

See info '(gdb)Checkpoint/Restart' but it does not work with threads and it is
not a commonly used feature (at least I have never used it myself).


Regards,
Jan

Re: help with loading core files

[Michael Snyder]

Jan Kratochvil wrote:
> On Thu, 22 Jul 2010 19:55:03 +0200, Mathew Yeates wrote:
>> How do people deal with running to a breakpoint that takes 10 minutes
>> to get to? It would be great if I could run to the breakpoint once,
>> save some info, and in the future just return to the breakpoint and
>> keep running from there.
> 
> See info '(gdb)Checkpoint/Restart' but it does not work with threads and it is
> not a commonly used feature (at least I have never used it myself).

Jan, I think he wants to quit his gdb session and return to it.
Checkpoints aren't preserved across quitting and restarting gdb.

Re: help with loading core files

[Mathew Yeates]

yeah, I was just looking at "checkpoint". It seems to me that if gdb
is able to create checkpoints, it should also be able to do what I
want (restart and immediately go to a certain location)

On Thu, Jul 22, 2010 at 11:09 AM, Michael Snyder <msnyder@vmware.com> wrote:
> Jan Kratochvil wrote:
>>
>> On Thu, 22 Jul 2010 19:55:03 +0200, Mathew Yeates wrote:
>>>
>>> How do people deal with running to a breakpoint that takes 10 minutes
>>> to get to? It would be great if I could run to the breakpoint once,
>>> save some info, and in the future just return to the breakpoint and
>>> keep running from there.
>>
>> See info '(gdb)Checkpoint/Restart' but it does not work with threads and
>> it is
>> not a commonly used feature (at least I have never used it myself).
>
> Jan, I think he wants to quit his gdb session and return to it.
> Checkpoints aren't preserved across quitting and restarting gdb.
>

Re: help with loading core files

[Jan Kratochvil]

On Thu, 22 Jul 2010 20:14:16 +0200, Mathew Yeates wrote:
> yeah, I was just looking at "checkpoint". It seems to me that if gdb
> is able to create checkpoints, it should also be able to do what I
> want (restart and immediately go to a certain location)

AFAIK there exist such general process snapshot tools for clusters but I do
not know these.

I have only experience with virtual machines (qemu-kvm, see savevm and loadvm)
where you can snapshot the whole virtual machine with the debugger + debuggee.


Regards,
Jan

Re: help with loading core files

[Steffen Dettmer]

On Thu, Jul 22, 2010 at 8:18 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> I have only experience with virtual machines (qemu-kvm, see
> savevm and loadvm) where you can snapshot the whole virtual
> machine with the debugger + debuggee.

ohh, this sounds like a great idea!

How long does it approximately take to prepare such a `retry'?
Is it a matter of very few seconds only?

oki,

Steffen

Re: help with loading core files

[Jan Kratochvil]

On Wed, 28 Jul 2010 11:06:22 +0200, Steffen Dettmer wrote:
> On Thu, Jul 22, 2010 at 8:18 PM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
> > I have only experience with virtual machines (qemu-kvm, see
> > savevm and loadvm) where you can snapshot the whole virtual
> > machine with the debugger + debuggee.
> 
> ohh, this sounds like a great idea!
> 
> How long does it approximately take to prepare such a `retry'?
> Is it a matter of very few seconds only?

Yes, ctrl-alt-2, "loadvm a", ctrl-alt-1 takes about 1 second, "savevm b" takes
~3 seconds.  See: http://wiki.qemu.org/download/qemu-doc.html#vm_005fsnapshots

If you run qemu-kvm by hand it does some fsync() by default (#$!@#$!@#), you
should mount your disk using: -drive file=test.qcow2,cache=writeback

Use recent host Linux kernel, older kernels had buggy debug registers in KVM.
Run testsuite in your guest: http://sourceware.org/systemtap/wiki/utrace/tests


Regards,
Jan

Re: help with loading core files

[Steffen Dettmer]

On Thu, Jul 22, 2010 at 7:55 PM, Mathew Yeates <mat.yeates@gmail.com> wrote:
> How do people deal with running to a breakpoint that takes 10 minutes
> to get to? It would be great if I could run to the breakpoint once,
> save some info, and in the future just return to the breakpoint and
> keep running from there.

I usually write a mock called by a automated unit test and run it
in gdb with full debug log messages enabled.
If the first run does not reveal enough information (e.g. uhh,
what was in variable x at this and that point?), it is a good
opportunity to improve the log messages.
When using an appropriate mock, it can be simple to call the
problematic function again, even from gdb (e.g. `print myFunc()').

oki,

Steffen