home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / admin / 4824 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  1.3 KB
  1. Xref: sparky comp.unix.admin:4824 comp.unix.questions:10624 comp.unix.shell:3747
  2. Path: sparky!uunet!mcsun!uknet!stl!robobar!ibmpcug!impmh!dsg
  3. From: dsg@impmh.uucp (Dave Gordon)
  4. Newsgroups: comp.unix.admin,comp.unix.questions,comp.unix.shell
  5. Subject: Re: How to prevent a large core-dump
  6. Message-ID: <1992Sep1.150813.1695@impmh.uucp>
  7. Date: 1 Sep 92 15:08:13 GMT
  8. References: <1992Aug25.173056.13401@utwente.nl>
  9. Organization: Integrated Micro Products Ltd
  10. Lines: 20
  11.  
  12. In <1992Aug25.173056.13401@utwente.nl> soos@math.utwente.nl (Adwin Soos) writes:
  13.  
  14. >A few weeks or even months ago I have read some discussion about the problem
  15. >of preventing a core-dump. I remember that there were some suggestions on how
  16. >to prevent that a large core-dump will be made. 
  17. >This problem is now occurring at our place where someone is writing a large
  18. >program and in some test-cases there is a core dump for more than 60 Mb.
  19. >This person is not using this core to debug it so maybe we can just stop the
  20. >creation of this core for this person.
  21.  
  22. One simple method that should work on all UN*X systems is to create a file
  23. named "core" in the working directory of the offending program, and give
  24. it no permissions:
  25.     echo > core
  26.     chmod 0 core
  27. Then the program will not produce a core, since the file "core" already
  28. exists, but is unwritable (see signal(2)).
  29. -- 
  30.             Dave
  31.             ====
  32.