home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / 18684 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  1.6 KB
  1. Xref: sparky comp.sys.sgi:18684 comp.unix.programmer:5889
  2. Newsgroups: comp.sys.sgi,comp.unix.programmer
  3. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!att!dptg!rjf
  4. From: rjf@lincroftnj.ncr.com (51351[efw]-Robert Feddeler(MT4799)T343)
  5. Subject: Re: developing under sys 5 unix
  6. Message-ID: <1993Jan11.202845.12276@lincroftnj.ncr.com>
  7. Organization: AT&T/NCR, Lincroft, NJ, USA
  8. References: <1993Jan11.190843.6808@CSD-NewsHost.Stanford.EDU>
  9. Distribution: usa
  10. Date: Mon, 11 Jan 1993 20:28:45 GMT
  11. Lines: 25
  12.  
  13. In article <1993Jan11.190843.6808@CSD-NewsHost.Stanford.EDU> vahe@sparcy.Stanford.EDU (Vahe Avedissian) writes:
  14. >I don't know if anyone else has the same experience,
  15. >but I am always frustrated, and my patience tested
  16. >when developing on SGI or other machines running
  17. >Sys 5 unix.
  18. >
  19. >The real annoying thing is once you run a program
  20. >with a bug, the system tends to completely stop responding
  21. >to interrupts or anything else, the windowing
  22. >system and manager are rendered unresponsive too.
  23. >You just sit there and wait for the system to eventually
  24. >(i.e. anywhere from 3 - 10 minutes or so) core dump.
  25. >
  26.  
  27. I've experienced this a few of times.  The bug always turns out
  28. to be an out-of-control recursive function.  The process eventually
  29. runs out of swap space or exceeds the limits on process virtual memory
  30. as the stack grows.  It takes a while to page all that stack out, and
  31. then read it back and write the 'core' file.
  32.  
  33. Try a smaller, faster disk...  {8^)
  34.  
  35.  
  36. bob.            | Heap big trouble in the land of plenty.
  37. Were these more than just my opinions, they would have cost a bit more.
  38.