regoli@silver.bacs.indiana.edu (michael regoli) (05/18/89)
][ what can you do with a core dump? when exiting from, say, a hung ftp session with ^\, what can you tell from the core file as to what happened and why? how do you find out? -- michael regoli regoli@silver.bacs.indiana.edu ...rutgers!iuvax!silver!regoli
chris@mimsy.UUCP (Chris Torek) (05/18/89)
In article <4016@silver.bacs.indiana.edu> regoli@silver.bacs.indiana.edu (michael regoli) writes: >what can you do with a core dump? A core file contains the exact state of the process%, even including such things as open file descriptors. Given the program itself and a symbol table (and a debugger), you can extract a stack trace, examine variables, and do anything else the debugger can do. >when exiting from, say, a hung ftp session with ^\, what can you tell >from the core file as to what happened and why? how do you find out? Since ftp clients usually hang because the server to which they were listening simply stops speaking, the core file usually tells you nothing you did not already know. ----- % Since this is unix.questions, not unix.wizards, we can ignore per- process state that appears only in the proc table not in u. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mike@hpfcdc.HP.COM (Mike McNelly) (05/19/89)
If you have source code, most symbollic debuggers will use the core file to point to the source line where the fatal error was detected (NOT where it occurred). You can also usually get a stack trace, variable values at the time of death, etc. Mike McNelly mike%hpfcla@hplabs.hp.com
peter@ficc.uu.net (Peter da Silva) (06/21/89)
My absolutely favorite thing to do with a core dump is turn it into an executable again. I used to do this to make snapshots of FORTH programs back in V7 days, and it was very useful. The original inspiration came from good old Adventure (the 350 point version), of course. How to do it? Well, in V7 it was easy... a.out and core formats were almost identical. Today... I don't know. have to look into it some time. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
dg@lakart.UUCP (David Goodenough) (06/23/89)
From article <4644@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): > My absolutely favorite thing to do with a core dump is turn it into an > executable again. I used to do this to make snapshots of FORTH programs > back in V7 days, and it was very useful. The original inspiration came > from good old Adventure (the 350 point version), of course. > > How to do it? Well, in V7 it was easy... a.out and core formats were almost > identical. Today... I don't know. have to look into it some time. Doesn't emacs do that already in some implementations. I was trying to install it (what a joke :-) ) and part of the Makefile talked about # run the program - it'll crash and dump core, but we want the core image BTW does anyone have a version of emacs source that doesn't require a FUBAR crt0.o - I am still waiting for a reasonable explanation as to why an executable (or a sensibly written one) needs anything other than the standard crt0.o. Alternatively if you have an executable emacs that will run on an Integrated Solutions Optimum V24, 68020, 4.3BSD, please uuencode it and send it my way. What _I_ do with coredumps is print them in hex (or octal if I'm feeling truly religious), then take the listing home. Makes great wallpaper ..... and I can debug the Kernel as I'm going to sleep ..... -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
guy@auspex.auspex.com (Guy Harris) (06/29/89)
>How to do it? Well, in V7 it was easy... a.out and core formats were almost >identical. Nonsense. In V7 as distributed by AT&T, core files consisted of the U area of the process, followed by the data and stack segments; it did not include an a.out header, nor did it include the text of the program, unless the program was not built with shared text or split I&D space (i.e. the program was built without any text).
kannan@babcock.cerc.wvu.wvnet.edu (R. Kannan) (07/22/89)
From article <4016@silver.bacs.indiana.edu>, by regoli@silver.bacs.indiana.edu (michael regoli): > > what can you do with a core dump? > > when exiting from, say, a hung ftp session with ^\, what can you tell > from the core file as to what happened and why? how do you find out? > ...rutgers!iuvax!silver!regoli there is a UNIX utility called "strings" USAGE: strings core Effect: Will output all printable characters from the file which here is the "core" Thus you can peek into the "core" and get some idea as to what happened. PS: The fact that I have tried and played with "core" is a convincing proof that I am not UNIX person yet. I am sure there are better things one can do to find exactly what happened. Thai is the reason core is created, I would think. --kannan
ked@garnet.berkeley.edu (Earl H. Kinmonth) (07/22/89)
>> what can you do with a core dump?
If the dump is from a stripped executable not very much. If the
executable was not stripped, you can use adb (RTFM) and determine
where (to the routine level) the programme tossed its cookies.
With luck you might even see the bad parameter by using the stack
backtrace command.glen@astroatc.UUCP (Glen Ecklund) (08/02/89)
In article <25588@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:
->>> what can you do with a core dump?
->
->If the dump is from a stripped executable not very much. If the
->executable was not stripped, you can use adb (RTFM) and determine
->where (to the routine level) the programme tossed its cookies.
->With luck you might even see the bad parameter by using the stack
->backtrace command.
adb? Gee, I thought everybody at Berkeley would know about dbx.
Glenfriedl@vsi.COM (Stephen J. Friedl) (08/03/89)
In article <2488@astroatc.UUCP>, glen@astroatc.UUCP (Glen Ecklund) writes: > > adb? Gee, I thought everybody at Berkeley would know about dbx. > Real Programmers don't use symbolic debuggers. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / {attmail uunet}!vsi!{bang!}friedl / friedl@vsi.com ^^^^^^^^^^^^^^^^^ "My new address is vsi bang bang bang friedl" - me
spee@qmfl.qmflp.JUNET (Paul SPEE) (08/04/89)
In article <2488@astroatc.UUCP> glen@astroatc.UUCP (Glen Ecklund) writes: >In article <25588@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >->If the executable was not stripped, you can use adb (RTFM) and determine >adb? Gee, I thought everybody at Berkeley would know about dbx. Professor Kinmonth is a japanologist and a member of the History Department, University of California, Davis. He would not post to comp.unix.wizards. Paul Spee spee%paul.qmflp.junet@RELAY.CS.NET #include <disclaimer.h>
dg@lakart.UUCP (David Goodenough) (08/06/89)
From article <2488@astroatc.UUCP>, by glen@astroatc.UUCP (Glen Ecklund): > adb? Gee, I thought everybody at Berkeley would know about dbx. > > Glen Yep, and dbx is even less use than adb if the program wasn't compiled with a -g option. Try taking dbx to a non -g executable. A fate usually reserved for masochists :-) -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
glen@astroatc.UUCP (Glen Ecklund) (08/08/89)
In article <645@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Yep, and dbx is even less use than adb if the program wasn't compiled with >a -g option. Try taking dbx to a non -g executable. A fate usually reserved >for masochists :-) I do it all the time. So do others who used to use adb. I don't know adb, and don't wish to know it, because it is so ugly. BTW, I have fixed up and enhanced dbx, so maybe genuine limitations in your dbx are at issue, but the only things I can think of off-hand that I had to add to dbx from adb were the ability to modify the object file, and the ability to specify relocation address (mainly for kernel debugging). I guess I would like to take advantage of this opportunity to ask, "Are there any other features which adb users find missing in dbx?" Please email to me. Thanks. Glen
rogerk@mips.COM (Roger B.A. Klorese) (08/12/89)
In article <645@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >Yep, and dbx is even less use than adb if the program wasn't compiled with >a -g option. Try taking dbx to a non -g executable. A fate usually reserved >for masochists :-) Works fine with Mips' dbx. Full instruction-level debugging... -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/24/89)
Paper your cat's litter box.