home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sgi:18689 comp.unix.programmer:5891
- Newsgroups: comp.sys.sgi,comp.unix.programmer
- Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!pangea.Stanford.EDU!karish
- From: karish@pangea.Stanford.EDU (Chuck Karish)
- Subject: Re: developing under sys 5 unix
- Message-ID: <1993Jan11.214558.11272@leland.Stanford.EDU>
- Sender: news@leland.Stanford.EDU (Mr News)
- Organization: DSO, Stanford University
- References: <1993Jan11.190843.6808@CSD-NewsHost.Stanford.EDU> <1993Jan11.202845.12276@lincroftnj.ncr.com>
- Distribution: usa
- Date: Mon, 11 Jan 93 21:45:58 GMT
- Lines: 29
-
- In article <1993Jan11.202845.12276@lincroftnj.ncr.com>
- rjf@lincroftnj.ncr.com (51351[efw]-Robert Feddeler(MT4799)T343) writes:
- |In article <1993Jan11.190843.6808@CSD-NewsHost.Stanford.EDU>
- vahe@sparcy.Stanford.EDU (Vahe Avedissian) writes:
-
- Hi, Vahe!
-
- ||The real annoying thing is once you run a program
- ||with a bug, the system tends to completely stop responding
- ||to interrupts or anything else, the windowing
- ||system and manager are rendered unresponsive too.
- ||You just sit there and wait for the system to eventually
- ||(i.e. anywhere from 3 - 10 minutes or so) core dump.
- |
- |I've experienced this a few of times. The bug always turns out
- |to be an out-of-control recursive function. The process eventually
- |runs out of swap space or exceeds the limits on process virtual memory
- |as the stack grows. It takes a while to page all that stack out, and
- |then read it back and write the 'core' file.
- |
- |Try a smaller, faster disk... {8^)
-
- Or use csh for your shell, and use 'limit stacksize' and
- 'limit coredumpsize' to keep the process from being such
- a resource hog.
- --
-
- Chuck Karish karish@mindcraft.com
- (415) 323-9000 x117 karish@pangea.stanford.edu
-