Core dumps

Core dumps

[Russell Shaw]

Hi,
When i make my code core-dump using abort(), and read the
core with "target core core", the back-trace shows a corrupted
stack. How do i make a core dump that has an intact stack i can
trace thru? Should i use something other than abort()?

Re: Core dumps

[Mark Kettenis]

> Date: Mon, 09 Jan 2006 20:33:04 +1100
> From: Russell Shaw <rjshaw@netspace.net.au>
> 
> Hi,
> When i make my code core-dump using abort(), and read the
> core with "target core core", the back-trace shows a corrupted
> stack. How do i make a core dump that has an intact stack i can
> trace thru? Should i use something other than abort()?

Sorry, but you don't provide nearly enough information to enable us to
answer your question.  At least we need to know what OS, what hardware
platform, what version of GDB and what version of GCC you're using.
It'd help us even more if you could provide a typescript of a GDB
session that show us your problem.

Thanks,

Mark

Re: Core dumps

[Russell Shaw]

Mark Kettenis wrote:
>>Date: Mon, 09 Jan 2006 20:33:04 +1100
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>
>>Hi,
>>When i make my code core-dump using abort(), and read the
>>core with "target core core", the back-trace shows a corrupted
>>stack. How do i make a core dump that has an intact stack i can
>>trace thru? Should i use something other than abort()?
> 
> Sorry, but you don't provide nearly enough information to enable us to
> answer your question.  At least we need to know what OS, what hardware
> platform, what version of GDB and what version of GCC you're using.
> It'd help us even more if you could provide a typescript of a GDB
> session that show us your problem.

I'm using debian-sid.

GNU gdb 6.3-debian
gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)

In gdb, i did:

(gdb) target core core
(gdb) bt

I get a long backtrace of "?" and a note saying corrupt stack.

I can't get a new core file to happen now, despite the
program hitting abort() or raise(11). I have ulimit unlimited.

Re: Core dumps

[Mark Kettenis]

> Date: Tue, 10 Jan 2006 22:29:47 +1100
> From: Russell Shaw <rjshaw@netspace.net.au>
> 
> I'm using debian-sid.

Well, that narrows it down...

...but not nearly enough.  Well, I suppose you're on i386 GNU/Linux.

> GNU gdb 6.3-debian
> gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)

So that's a Debian-modified gdb, have you tried asking for help on any
of the Debian lists?

> In gdb, i did:
> 
> (gdb) target core core
> (gdb) bt
> 
> I get a long backtrace of "?" and a note saying corrupt stack.
> 
> I can't get a new core file to happen now, despite the
> program hitting abort() or raise(11). I have ulimit unlimited.

Well, I can't be of much help then.

Mark

Re: Core dumps

[Daniel Jacobowitz]

On Tue, Jan 10, 2006 at 08:16:24PM +0100, Mark Kettenis wrote:
> > Date: Tue, 10 Jan 2006 22:29:47 +1100
> > From: Russell Shaw <rjshaw@netspace.net.au>
> > 
> > I'm using debian-sid.
> 
> Well, that narrows it down...
> 
> ...but not nearly enough.  Well, I suppose you're on i386 GNU/Linux.
> 
> > GNU gdb 6.3-debian
> > gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
> 
> So that's a Debian-modified gdb, have you tried asking for help on any
> of the Debian lists?

It's only lightly modified (by me).  But, I would need the same
information that Mark's been asking for in order to help...
especially, actual traces of GDB output.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Core dumps

[Russell Shaw]

Daniel Jacobowitz wrote:
> On Tue, Jan 10, 2006 at 08:16:24PM +0100, Mark Kettenis wrote:
> 
>>>Date: Tue, 10 Jan 2006 22:29:47 +1100
>>>From: Russell Shaw <rjshaw@netspace.net.au>
>>>
>>>I'm using debian-sid.
>>
>>Well, that narrows it down...
>>
>>...but not nearly enough.  Well, I suppose you're on i386 GNU/Linux.
>>
>>
>>>GNU gdb 6.3-debian
>>>gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
>>
>>So that's a Debian-modified gdb, have you tried asking for help on any
>>of the Debian lists?
> 
> It's only lightly modified (by me).  But, I would need the same
> information that Mark's been asking for in order to help...
> especially, actual traces of GDB output.

What's the best way to force a core-dump from my own code?
(I couldn't find much on the net)

Re: Core dumps

[Larry Martell]

--- Russell Shaw <rjshaw@netspace.net.au> wrote:
> What's the best way to force a core-dump from my own
> code?
> (I couldn't find much on the net)

Doesn't a SIGABRT (kill -6) force a core dump?

HTH,
-larry

Re: Core dumps

[Russell Shaw]

Larry Martell wrote:
> --- Russell Shaw <rjshaw@netspace.net.au> wrote:
> 
>>What's the best way to force a core-dump from my own
>>code?
>>(I couldn't find much on the net)
> 
> Doesn't a SIGABRT (kill -6) force a core dump?

I put this in my own code, but it still doesn't make a
core file:

   printf("Aborting...\n");
   raise(6);

I'm using debian-sid on a PC.

Re: Core dumps

[Eli Zaretskii]

> Date: Wed, 11 Jan 2006 12:52:18 +1100
> From: Russell Shaw <rjshaw@netspace.net.au>
> Cc: gdb@sources.redhat.com
> 
> > Doesn't a SIGABRT (kill -6) force a core dump?
> 
> I put this in my own code, but it still doesn't make a
> core file:
> 
>    printf("Aborting...\n");
>    raise(6);

Probably because your shell's init file(s) specify that the limit on
core files is zero bytes.  Use `ulimit' to change that to `unlimited'.

Re: Core dumps

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Wed, 11 Jan 2006 12:52:18 +1100
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>Cc: gdb@sources.redhat.com
>>
>>>Doesn't a SIGABRT (kill -6) force a core dump?
>>
>>I put this in my own code, but it still doesn't make a
>>core file:
>>
>>   printf("Aborting...\n");
>>   raise(6);
> 
> Probably because your shell's init file(s) specify that the limit on
> core files is zero bytes.  Use `ulimit' to change that to `unlimited'.

$russell@home~: ulimit
$unlimited

What else can i try?

Re: Core dumps

[Joel Brobecker]

> $russell@home~: ulimit
> $unlimited
> 
> What else can i try?

What shell do you use? I use zsh, and I have to use "ulimit -c" to
modify the core-file size:

        %ulimit
        unlimited
        %ulimit -a
        cpu time (seconds)         unlimited
        file size (blocks)         unlimited
        data seg size (kbytes)     unlimited
        stack size (kbytes)        8192
        core file size (blocks)    0
        unlimited
        processes                  4093
        file descriptors           1024
        locked-in-memory size (kb) unlimited
        memory size (kb)           unlimited
        file locks                 unlimited
        %ulimit -c 2000000
        %ulimit -a
        cpu time (seconds)         unlimited
        file size (blocks)         unlimited
        data seg size (kbytes)     unlimited
        stack size (kbytes)        8192
        core file size (blocks)    2000000
        unlimited
        processes                  4093
        file descriptors           1024
        locked-in-memory size (kb) unlimited
        memory size (kb)           unlimited
        file locks                 unlimited

-- 
Joel

Re: Core dumps

[Russell Shaw]

Joel Brobecker wrote:
>>$russell@home~: ulimit
>>$unlimited
>>
>>What else can i try?
> 
> What shell do you use?

russell@home~: bash --version
GNU bash, version 3.00.16(1)-release (i486-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.

 > I use zsh, and I have to use "ulimit -c" to
> modify the core-file size:
> 
>         %ulimit
>         unlimited
>         %ulimit -a
>         cpu time (seconds)         unlimited
>         file size (blocks)         unlimited
>         data seg size (kbytes)     unlimited
>         stack size (kbytes)        8192
>         core file size (blocks)    0
>         unlimited
>         processes                  4093
>         file descriptors           1024
>         locked-in-memory size (kb) unlimited
>         memory size (kb)           unlimited
>         file locks                 unlimited
>         %ulimit -c 2000000
>         %ulimit -a
>         cpu time (seconds)         unlimited
>         file size (blocks)         unlimited
>         data seg size (kbytes)     unlimited
>         stack size (kbytes)        8192
>         core file size (blocks)    2000000
>         unlimited
>         processes                  4093
>         file descriptors           1024
>         locked-in-memory size (kb) unlimited
>         memory size (kb)           unlimited
>         file locks                 unlimited
> 

russell@home~: ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) unlimited
virtual memory        (kbytes, -v) unlimited


Well that seems to say it all;)

"man ulimit" has a useless man page. However, i just
tried "help ulimit" which shows all the options;)

The backtrace in gdb is working correctly this time.
I seemed to get core files sometimes, despite not
having set ulimit -c. Maybe gdb was doing that.

Re: Core dumps

[Larry Martell]

--- Russell Shaw <rjshaw@netspace.net.au> wrote:
> Eli Zaretskii wrote:
> >>Date: Wed, 11 Jan 2006 12:52:18 +1100
> >>From: Russell Shaw <rjshaw@netspace.net.au>
> >>Cc: gdb@sources.redhat.com
> >>
> >>>Doesn't a SIGABRT (kill -6) force a core dump?
> >>
> >>I put this in my own code, but it still doesn't
> make a
> >>core file:
> >>
> >>   printf("Aborting...\n");
> >>   raise(6);
> >
> > Probably because your shell's init file(s) specify
> that the limit on
> > core files is zero bytes.  Use `ulimit' to change
> that to `unlimited'.
> 
> $russell@home~: ulimit
> $unlimited
> 
> What else can i try?

ulimit -c unlimited

Re: Core dumps

[Russell Shaw]

Mark Kettenis wrote:
>>Date: Mon, 09 Jan 2006 20:33:04 +1100
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>
>>Hi,
>>When i make my code core-dump using abort(), and read the
>>core with "target core core", the back-trace shows a corrupted
>>stack. How do i make a core dump that has an intact stack i can
>>trace thru? Should i use something other than abort()?
> 
> Sorry, but you don't provide nearly enough information to enable us to
> answer your question.  At least we need to know what OS, what hardware
> platform, what version of GDB and what version of GCC you're using.
> It'd help us even more if you could provide a typescript of a GDB
> session that show us your problem.

I'm using debian-sid on a PC.

GNU gdb 6.3-debian
gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)

In gdb, i did:

(gdb) target core core
(gdb) bt

I get a long backtrace of "?" and a note saying corrupt stack.

I can't get a new core file to happen now, despite the
program hitting abort() or raise(11). I have ulimit unlimited.

Re: Core dumps

[Bapi]

Hi,
The process i m debugging dumps core after 5 days .Is there any means by
which i can simulate the problem any time ? 
Thanx
-- 
View this message in context: http://www.nabble.com/Core-dumps-tf878636.html#a7612896
Sent from the gdb - General mailing list archive at Nabble.com.

Re: Core dumps

[Nick Roberts]

 > The process i m debugging dumps core after 5 days .Is there any means by
 > which i can simulate the problem any time ? 

You're appear to be asking a question about your program not about GDB.
Inspecting the core should help to answer your question.  Debugging the process
means running under GDB - if you're not you should be - in which case a signal
should stop execution before dumping the core, when you can examine the cause
more carefully.

-- 
Nick                                           http://www.inet.net.nz/~nickrob