home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / admin / 4843 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  1.4 KB
  1. Xref: sparky comp.unix.admin:4843 comp.unix.questions:10652 comp.unix.shell:3773
  2. Path: sparky!uunet!pmafire!news.dell.com!swrinde!sdd.hp.com!wupost!gumby!destroyer!ncar!vexcel!copper!slate!mbarkah
  3. From: mbarkah@slate.mines.colorado.edu (Ade Barkah)
  4. Newsgroups: comp.unix.admin,comp.unix.questions,comp.unix.shell
  5. Subject: Re: How to prevent a large core-dump
  6. Message-ID: <1992Sep2.155211.10164@slate.mines.colorado.edu>
  7. Date: 2 Sep 92 15:52:11 GMT
  8. References: <1992Sep2.94728.26099@ms.uky.edu>
  9. Distribution: na
  10. Organization: Colorado School of Mines
  11. Lines: 25
  12.  
  13. kherron@ms.uky.edu (Kenneth Herron) writes:
  14. : msb@sq.sq.com (Mark Brader) writes:
  15. : 
  16. : >>     echo > core
  17. : >>     chmod 0 core
  18. : >> Then the program will not produce a core, since the file "core" already
  19. : >> exists, but is unwritable (see signal(2)).
  20. : 
  21. : >Fine for most purposes, probably including the original query, but wait
  22. : >until the day that it's a setuid-root program whose core dumps you want
  23. : >to prevent!
  24. : >    mkdir core
  25. : 
  26. : You won't get a core dump if the executable is stripped.  Am I the only
  27. : one who's noticed this?
  28.  
  29. But, but, you can't debug no more when it's stripped... so how's
  30. one supposed to fix that core dump ? :)
  31.  
  32. -Ade.
  33. -- 
  34. Internet  : mbarkah@slate.mines.colorado.edu    (NeXT Mailable)
  35. CompuServe: 74160,3404
  36. FIDO_net  : Ade Barkah [1:104/108@fido.org]
  37. SNAIL_net : 1800 West Campus Road, Golden, CO 80401
  38.