home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / hp / 10105 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  1.9 KB
  1. Xref: sparky comp.sys.hp:10105 comp.unix.admin:4896
  2. Newsgroups: comp.sys.hp,comp.unix.admin,ctp.it
  3. Path: sparky!uunet!usc!sdd.hp.com!scd.hp.com!cupnews0.cup.hp.com!pdg
  4. From: pdg@cup.hp.com (Paul Gootherts)
  5. Subject: Re: Enormous core dumps
  6. Sender: news@cupnews0.cup.hp.com
  7. Message-ID: <Bu4tCB.BG5@cup.hp.com>
  8. Date: Sun, 6 Sep 1992 00:57:47 GMT
  9. References: <1992Sep4.163132.22011@ctp.com>
  10. Organization: Hewlett-Packard
  11. X-Newsreader: Tin 1.1.3 PL5
  12. Lines: 32
  13.  
  14. > What kinds of problems can lead to processes crashing and leaving behind
  15. > huge (for example, we had a 50 megabyte one this morning) core files?
  16. > I know how to limit this with limit or ulimit, but I'd like to know
  17. > more about the events that can cause such core dumps to occur.
  18.  
  19. Program crashes that leave core files are usually caused by receipt of a
  20. signal that was not being caught or ignored.  A list of the signals that
  21. cause core dumps can be found on signal(5).  I believe note "B"
  22. indicates which signals cause core files.
  23.  
  24. Such a signal could be sent by the process itself, another process, or
  25. it could have been generated by the kernel in response to something the
  26. process tried to do.  For example, dereferencing an (int *) whose value
  27. is not word aligned (a multiple of 4) will cause a SIGBUS.
  28.  
  29. As to the size of the core file:  It could have been a big program when
  30. it was exec'd.  Run size(1) on the a.out to check.  The data and bss
  31. sizes contribute to the size of core files.  The text size does not.
  32.  
  33. Or it could have grown while it was running.  This happens when the
  34. stack and/or data areas grow.
  35.  
  36. Procedure calls can grow the stack.  Look for runaway recursion or a
  37. procedure with an enormous number local variables or really huge local
  38. variables.  (Locals go on the stack.)
  39.  
  40. The data area grows when you call brk(2) or sbrk(2).  These may have
  41. been called on your behalf by malloc(3) or a relation.
  42.  
  43. --
  44.  
  45. Paul Gootherts, pdg@cup.hp.com
  46.