Angus Lees <[EMAIL PROTECTED]>
> On Tue, Jul 11, 2000 at 02:21:17PM +1000, Peter Rundle wrote:
> > Ok you've caught me out faking Linux expertise, I have no idea where to
> > even start with doing a core debug....
>
> just because i think core dumps are _way_ underrated:
>
> gdb <executable> <corefile>
>
> at the gdb prompt, type things like "where" to find out where the
> program crashed.
>
> if the executable has debugging symbols compiled in, you'll get a
> pretty backtrace (and be able to look at variable values, etc). if it
> doesn't, then you'll just get assembly and the odd cryptic linker
> symbol (which may still be useful).
>
> i think its a real shame that core dumps are turned off (the size is
> limited to 0. see ulimit(1), limit(1) or getrlimit(2)) by default on
> most linux distros. core dumps are an excellent way of catching those
> one-in-a-million unreproducible bugs, without slowing your program
> down with debugging code.
>
> and if you find a stray core file, "file core" will usually be able to
> tell you what program produced the core dump
I've left all of Angus' response in here cos it's all true and
worth reading again
I haven't used gdb, only adb, and all I really know is to
fire up "adb <executable> <corefile>", then do "$c" for
a stack trace (and "$q" to quit).
The stack trace will almost always tell you what went wrong.
Not in much detail sometimes but usually enough to give you
a hint what the problem was (or at least where it was).
Dave.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
