scott@texnext.gac.edu (Scott Hess) (04/04/91)
In release 2.0 of NextStep, NeXT for some reason decided to remove the
previous default coredumpsize=0 for Workspace-spawned processes, and
replaced it with coredumpsize=16M. While this is fine in some cases,
in most (almost all, in fact) it's sort of silly. For instance, not
many people have a use for an Icon core, much less a Mathematica
core.
Admittedly, you can change this back, also you could for the template
new-user account. [BTW: I've not been able to figure out what the
correct default is for dwrite. Or is there one? I know there is,
because _I_ don't get cores while our new users do, but for the life
of me I cannot find it, NextAnswers or no -scott] But it's a bother
to have to do this, and in most cases people won't remember to.
So, what I would like is for people to insert the following code,
or something much like it, into their distributed programs. This
will cause you program _not_ to dump core if there are problems.
Since few (if any) of the users will have the source to debug
with anyhow, it's not a loss:
#import <appkit/Application.h>
#import <sys/time.h>
#import <sys/resource.h>
@implementation MyApp : App
+ initialize
{
struct rlimit rl={ 0, 0};
getrlimit( RLIMIT_CORE, &rl);
rl.rlim_cur=0;
setrlimit( RLIMIT_CORE, &rl);
return self;
}
@end
Later,
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Simply press Control-right-Shift while click-dragging the mouse . . ."
"I smoke the nose Lucifer . . . Banana, banana."tyc@cbnewse.att.com (felix.a.lugo) (04/06/91)
In article <SCOTT.91Apr4150850@texnext.gac.edu> scott@texnext.gac.edu (Scott Hess) writes: | In release 2.0 of NextStep, NeXT for some reason decided to remove the | previous default coredumpsize=0 for Workspace-spawned processes, and | replaced it with coredumpsize=16M. While this is fine in some cases, | in most (almost all, in fact) it's sort of silly. For instance, not | many people have a use for an Icon core, much less a Mathematica | core. | The 'defaults' name is "CoreLimit" (no quotes) for Workspace. Use $ dwrite Workspace CoreLimit 0 to turn off core files of apps launched by Workspace. (You need to log out and log back in for these changes to take effect.) For a quick test, launch the 2.0 Icon app and select the Edit menu item. Icon will exit immediately, but no core file is created (try it before you set CoreLimit and a core file will be made.) Another useful default is "ShellPath". This is the shell used by the New Shell menu in the Workspace (i.e. default is /bin/csh.) Use: $ dwrite Workspace ShellPath /bin/sh ... [self stuffDeleted] ... | Later, | -- | scott hess scott@gac.edu | Independent NeXT Developer GAC Undergrad | <I still speak for nobody> | "Simply press Control-right-Shift while click-dragging the mouse . . ." | "I smoke the nose Lucifer . . . Banana, banana." /* ** Felix A. Lugo ** ** E-Mail (including NeXTMail): ** Felix_A_Lugo@ATT.COM ** att!ihcoco!coco */
new@ee.udel.edu (Darren New) (04/06/91)
In article <SCOTT.91Apr4150850@texnext.gac.edu> scott@texnext.gac.edu (Scott Hess) writes: >So, what I would like is for people to insert the following code, >or something much like it, into their distributed programs. This >will cause you program _not_ to dump core if there are problems. >Since few (if any) of the users will have the source to debug >with anyhow, it's not a loss: Bad idea. Then when a user has problems with your program which you cannot duplicate, it is impossible for the user to send you a copy of the core file for you to inspect against your proprietary sources. Much better to just fix the problem properly using the inheritence of user limits as it was meant to be used. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+=+ My time is very valuable, but unfortunately only to me +=+=+ + When you drive screws with a hammer, screwdrivers are unrecognisable +
jiro@shaman.com (Jiro Nakamura) (04/07/91)
In article <49911@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes: >> [Setting it so a program won't core dump, ever] >Bad idea. Then when a user has problems with your program which you cannot >duplicate, it is impossible for the user to send you a copy of the core >file for you to inspect against your proprietary sources. Much better >to just fix the problem properly using the inheritence of user limits >as it was meant to be used. -- Darren A user once sent me a coredump of Cassandra. I was wondering why my Trailblazer seemed hung up on one file for a hell of a long time. :-( Getting multi-megabyte coredumps over a UUCP line isn't one's idea of fun. But I agree, the user should have the option of making his or her own coredump and debugging it with gdb if they really want to. Freedom to the users. :-) - jiro -- Jiro Nakamura jiro@shaman.com Shaman Consulting (607) 253-0687 VOICE "Bring your dead, dying shamans here!" (607) 253-7809 FAX/Modem
rca@cs.brown.edu (Ronald C.F. Antony) (04/09/91)
In article <SCOTT.91Apr4150850@texnext.gac.edu> scott@texnext.gac.edu (Scott Hess) writes: >in most (almost all, in fact) it's sort of silly. For instance, not >many people have a use for an Icon core, much less a Mathematica >core. > >Since few (if any) of the users will have the source to debug >with anyhow, it's not a loss: Well, but how about sending NeXTmail to the developer of the program with the core file included? As the file get compressed the size of that should be not too bad. And it is still far superior to any customer complaining that well, "He/she did it as always, but the suddenly..." and noone will ever have a clue what went wrong. Of course applications should not dump core in the first place :-) But if they do they should get debugged and to do so a programmer want a core file. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet
scott@mcs-server.gac.edu (Scott Hess) (04/11/91)
In article <71370@brunix.UUCP> rca@cs.brown.edu (Ronald C.F. Antony) writes: In article <SCOTT.91Apr4150850@texnext.gac.edu> scott@texnext.gac.edu (Scott Hess) writes: >in most (almost all, in fact) it's sort of silly. For instance, not >many people have a use for an Icon core, much less a Mathematica >core. > >Since few (if any) of the users will have the source to debug >with anyhow, it's not a loss: Well, but how about sending NeXTmail to the developer of the program with the core file included? As the file get compressed the size of that should be not too bad. And it is still far superior to any customer complaining that well, "He/she did it as always, but the suddenly..." and noone will ever have a clue what went wrong. Of course applications should not dump core in the first place :-) But if they do they should get debugged and to do so a programmer want a core file. Well, I've found cores to be of minimal debugging help. The main problem is that, without a full description of how the user got the program into the buggy state, I can't do much. Sure, knowing that the lineSize variable is too large at some point is nice, but unless I can step through the preceeding 100 lines of code, I'm not going to have any idea of _why_. (I've gotten core files through the mail for Stuart, and that's the experience I've had - might not be standard, who's to say?) Oh, well. It probably was a bad idea, anyhow :-) Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <I still speak for nobody> "Simply press Control-right-Shift while click-dragging the mouse . . ." "I smoke the nose Lucifer . . . Banana, banana."