Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!att!cbnews!gwe
From: gwe@cbnews.ATT.COM (George W. Erhart)
Newsgroups: comp.windows.x
Subject: Re: xperfmon under SunOs4.0*
Keywords: XPERFMON , SUNOS4.0*
Message-ID: <11590@cbnews.ATT.COM>
Date: 21 Nov 89 00:36:17 GMT
References: <726@corona.pb>
Reply-To: gwe@cbnews.ATT.COM (George W. Erhart,59474,cb,3E373,6148604021)
Organization: AT&T Bell Laboratories
Lines: 27

In article <726@corona.pb> hsg@pbinfo.UUCP (Joerg Hoyer) writes:
>If i = 3 in the second for-loop xperfmon dies in the following line:
>graph_list[i]->zero = graph_list[i]->min_pix + (graph_list[i]->min_value*SCALE(i));

	Note that SCALE(i) will cause your floating point exception if 
	graph_list[i]->max_value == 0 ... note further that when i is
	equal to 3, the draw_background() function is attempting to
	draw the background for the "Free" component of the display.

	Further investigation of this problem will show that in system.c,
	the structure nl[] contains the symbol names of the values in
	the vmunix kernel that hold things like the maximum amount of 
	free memory in the system. (Which equals the total amount of 
	RAM under SUN OS 3.5.) In SUN OS 3.5, the maximum amount of 
	free memory was contained in "_maxfree". This symbol is not
	in SUN OS 4.0.X. Thus, when nlist() returns a zero value for the
	maxfree memory, the SCALE() will fail in draw_background().

	I did not have time to find out what new symbol could be used
	to replace _maxfree, so I hardcoded the maximum of 24MB in
	my copy of system.c.

Have fun ... but remember that it is dangerous to play with kernels!
-- 
George Erhart
AT&T Network Systems/Bell Laboratories
att!cbdkc1!gwe