ron%brl-vgr@sri-unix.UUCP (10/31/83)
From: Ron Natalie <ron@brl-vgr> GACK: Ignoring exception signals. I hope you enjoy infinite loops. -Ron
SHAWN%mit-ml@sri-unix.UUCP (11/01/83)
From: Shawn F. McKay <SHAWN@mit-ml>
Why? if you don't reset the catch, it will core dump the second time,
if you use abort() however, I see your point, but then, you just get
rid of the abort() system call when debug is defined. If you reset
the catch, and have a loop counter, then there is no chance of a loop,
and even without a counter, I don't really see where looping comes in.
Something like this:
#include <stdio.h>
#include <signal.h>
int trap();
main()
{
signal(SIGQUIT, trap); /* bye bye sigquit */
.... body of program
}
trap()
{
signal(SIGQUIT, trap); /* reset for next time */
puts("Ouch!"); /* speak to me! */
}
should NOT loop(??).. if it does, please explain how...
Yours In Hacking,
-ShawnSHAWN%mit-ml@sri-unix.UUCP (11/01/83)
From: Shawn F. McKay <SHAWN@mit-ml> Yes. on all counts, however, I think makeing the file 0 mode, is kind of useless, as what if the user cd's to another directory he can write, and dumps, then all of a sudden, a core file is created.. I feel its better to 'trap' or SIG_IGN, when you don't wan't to deal with it, granted, SIG_IGN's are evil, but they work. The better way, (the one I pointed out in the last message, pointed out, what I feel to be the best way to deal with it, or even something more like a program that runs yours in a funny mode, where it traps signals destin to your program, does not allow a cure dumps, (via your enableing an option), and tells you about the core dump, somewhat like when you run a program in 'adb'. In fact, it sounds so good, I might just place this on my todo list.. Happy Hacking -Shawn
dbj.rice%rand-relay@sri-unix.UUCP (11/02/83)
From: Dave Johnson <dbj.rice@rand-relay>
4.1 will also not dump core if the file "core" is not a regular file (i.e.,
it is a device or directory or ...), or if it already existed before the
kernel tried to create it but belonged to somebody other than your current
real uid, or if you were running with your effective uid not equal to your
real uid (i.e., you were running a set uid program), or if the file has a
link count not equal to 1. None of these ways are any easier than using
vlimit or making the core file not writable, but just for completeness...
Dave Johnson
Dept. of Math Science
Rice University
dbj.rice@Rand-Relaydid%ucla-cs@sri-unix.UUCP (11/03/83)
From: David I. Dalva <did@ucla-cs> Don't you think the list has already beaten the core-dump issue to a pulp?
ron%brl-vgr@sri-unix.UUCP (11/07/83)
From: Ron Natalie <ron@brl-vgr> But that's not what you said. You said SIG_IGN. That's ignore. That means the program never has any indication that it trapped. This will either cause the program to continue errouneously or cause it to enter a rather strange loop. I feel that it is more versatile to disable core dumps external to the program because it allows the shell to still give you the notification of the exception and allows you to easily turn them back on again if you want them. The two ways of disabling core dumps, but keeping the standard exception processing demonstrated for 4.1 BSD so far are chaning the limit on the core dump size to zero or just making the file "core" such that it is non writable. Even if one was to use your method of ignoring exceptions, wouldn't it be easier to write a program similar to the "nohup" utility that sets all the signals to IGNORE and then execs the program, this would preclude having to modify the program to turn them on and off. -Ron
ron%brl-vgr@sri-unix.UUCP (11/09/83)
From: Ron Natalie <ron@brl-vgr> Of course the other way of stopping core dumps but still receiving notification of the exception is to ptrace the program. -Ron
isusesp@gt-oscar.UUCP (Scott Pfeffer) (02/24/86)
Does anyone have information/documentation on the structure of core dump
files (e.g. "core") on System V? I am working on some programs to examine
core files and display the values of variables, a trace of the stack, and
anything else I can get out of the a.out and core files that would be useful
to a person debugging a program.
There is plenty of useful documentation on a.out files, but I can
find very little on core files other than several ".h" include files
in the include/sys directory. If you can help, please send mail to me.
Thanks,
Scott Pfeffer