Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!mcsun!ukc!stl!crosfield!ir From: ir@crosfield.co.uk (ian reid) Newsgroups: comp.unix.sysv386 Subject: Re: u386mon dumping core (was: Re: out of swap space??) Message-ID: <9884@suns6.crosfield.co.uk> Date: 7 May 91 08:57:48 GMT References: <17@metran.UUCP> <1991Apr30.105615.9129@gallium.uucp> <1991May4.214132.27702@cti-software.nl> Reply-To: ir@crosfield.co.uk (ian reid) Followup-To: comp.unix.sysv386 Organization: Crosfield Electronics, Hemel Hempstead, United Kingdom. Lines: 26 In article <1991May4.214132.27702@cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes: >In article <17@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >> >>(Also, note that the current version of u386mon dumps core on ISC 2.2 >>systems if you try to access the process screen. On at least one system, >>anyway...) > >I've noticed that u386mon compiled on a 2.0.2 system will dump core >as described running on a 2.2 system. I had the problem of u386mon core dumping when going into the process screen. I tracked the problem down to a variable HZ being set to a null string in the environment. It is set in /etc/default/login to HZ=100 (on ISC 2.2.1), so why it should have turned up as a null string I don't know. Anyway u386mon uses HZ to do arithmetic, including using it as a divisor, hence the core dump. If HZ is not set in the environment u386mon uses the value in /usr/include/sys/param.h. The workaround was so simple that I didn't spend any time discovering why HZ was being improperly set in the environment. As I had u386mon wrapped up in a shell script I simply did an unset HZ and used the compiled in value. -- Ian Reid #include UUCP: ir@cel.uucp or ir@cel.co.uk or ...!{ukc,mcsun,uunet}!cel!ir "Computers..proof positive that no-one yet understands how to describe any real world situation in 0's and 1's."