cks@ziebmef.uucp (Chris Siebenmann) (12/23/88)
Every so often (once a day right now, it seems) *something* here is
dumping core in /etc/lddrv. The core file is owner root, group sys;
the latest one was dumped when the only thing going on was a UUCP
connection with my newsfeed. The cores run around 100K or so (the
latest one was 98304 bytes long), and while there's a crontab job that
fires up around that time, it seems to have completed without any
"core dumped" messages in its output. Everything seems to continue to
run fine; it's just making me nervous and chewing up some disk space
every now and then.
Any ideas on what program might dump core in /etc/lddrv? Any ideas on
how to identify what program produced a specific core dump? Is this
information stored anywhere in the core file?
Thanks in advance; reply by mail if possible and I'll summarize.
[The next hop on pathalias's preferred mail path to here just went
away; please route mail manually until the January maps come out.]
--
"You're a prisoner of the dark sky/The propeller blades are still
And the evil eye of the hurricane's/Coming in for the kill"
Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks
cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cksbrant@manta.pha.pa.us (Brant Cheikes) (12/25/88)
[Although Chris wrote > Thanks in advance; reply by mail if possible and I'll summarize. he also wrote >[The next hop on pathalias's preferred mail path to here just went >away; please route mail manually until the January maps come out.] I doubted the likelihood of mail to get thru with all the evil rerouters out there.] Chris Siebenmann writes: >Every so often (once a day right now, it seems) *something* here is >dumping core in /etc/lddrv. [...] >Any ideas on what program might dump core in /etc/lddrv? Any ideas on >how to identify what program produced a specific core dump? Is this >information stored anywhere in the core file? No, yes, and yes. If you know where to look, you can find the user structure, described in <sys/user.h>, in the core file. The user structure tells you all sorts of neat things about the core-dumping process, including its name. In C, first cfp = fopen(core_name, "r"); where core_name is the name of the core file you want to inspect. Then you must jump past the stuff (kernel stack data?) at the start of the core file: fseek(cfp, (long)U_OFFSET, 0); where U_OFFSET is defined in <sys/param.h>. Now you can just { struct user u; /* from <sys/user.h> */ fread(&u, sizeof(u), 1, cfp); /* print out useful data in u */ } >Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks >cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science brant@manta.pha.pa.us, brant@linc.cis.upenn.edu, bpa!manta!brant
alex@umbc3.UMD.EDU (Alex S. Crain) (12/28/88)
In article <460@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes: >If you know where to look, you can find the user structure, described in ><sys/user.h>, in the core file. The user structure tells you all sorts >of neat things about the core-dumping process, including its name. >In C, first > cfp = fopen(core_name, "r"); > fseek(cfp, (long)U_OFFSET, 0); >where U_OFFSET is defined in <sys/param.h>. Now you can just > { struct user u; /* from <sys/user.h> */ > fread(&u, sizeof(u), 1, cfp); > /* print out useful data in u */ > } You could also use that wonderful binary inspector, GNU emacs (if you have it) with emacs core_name ESC-ESC (goto-char 2304) where 2304 is decamil for 0x900 (U_OFFSET). -- :alex Alex Crain Systems Programmer alex@umbc3.umd.edu Univ Md Baltimore County nerwin!alex@umbc3.umd.edu