home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 15992 < prev    next >
Encoding:
Internet Message Format  |  1992-11-04  |  1.3 KB

  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!olivea!charnel!rat!usc!sdd.hp.com!saimiri.primate.wisc.edu!ames!agate!spool.mu.edu!uwm.edu!linac!unixhub!stanford.edu!leland.Stanford.EDU!dhinds
  2. From: dhinds@leland.Stanford.EDU (David Hinds)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Killed?
  5. Message-ID: <1992Nov4.203129.29035@leland.Stanford.EDU>
  6. Date: 4 Nov 92 20:31:29 GMT
  7. References: <1992Nov4.065527.4867@shannon.ee.wits.ac.za>
  8. Sender: news@leland.Stanford.EDU (Mr News)
  9. Organization: DSG, Stanford University, CA 94305, USA
  10. Lines: 17
  11.  
  12. In article <1992Nov4.065527.4867@shannon.ee.wits.ac.za> philip@concave.cs.wits.ac.za (Philip Machanick) writes:
  13. >Occasionally when I have a bug in a program or allocate a very large
  14. >data structure, my program dies with the message
  15. >  Killed.
  16. >This is not enourmously informative (whatever happened to core dumps)?
  17. >
  18. >What's going on?
  19.  
  20. I think this is what happens when a process exceeds the stack size
  21. resource limit.  The reason there is no core dump is that when the
  22. stack is full, there is no way to call the regular signal handler.
  23. You should get an error message in the SYSLOG, though.  You might be
  24. able to get around this by using the sigstack() call to specify an
  25. alternate stack for signal handlers; this requires -D_BSD_SIGNALS.
  26.  
  27.         - David Hinds
  28.           dhinds@allegro.stanford.edu
  29.