> can you give a little more details about how ganglia is failing? the left
> thing to do is for us to try and fix the cpu speed function to not crash.
I think you'll find most of your questions answered in my first email, but
I'll take another shot.
I'm running UML (user mode linux), with a minimal installation (e.g.,
busybox + a few misc. utils and the LAM MPI library). cpu_speed_func() is
failing because it calls strstr() and strchr() but doesn't check the return
values.
Under UML, /proc/cpuinfo does not contain the same information as normal
i386 Linux. It looks something like this:
processor : 0
vendor_id : User Mode Linux
model name : UML
mode : tt
host : Linux wolery 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002
i686
bogomips : 817.20
When the code is compiled, __i386__ is defined -- because UML binaries are,
at least in this instance, i386 binaries. Gmond attempts to do this:
p = strstr(p, "cpu MHz");
p = strchr(p, ':');
The first call to strstr() fails, returning a NULL pointer. The second
call to strchr() attempts to access a NULL pointer, thus causing a
segfault.
My proposal was to add error checking in cpu_speed_func() so that it looks
like this:
p = proc_cpuinfo;
p = strstr( p, "cpu MHz" );
if (! p) return val; // check strstr() return value.
p = strchr( p, ':' );
if (! p) return val; // check strchr() return value.
And so forth for the other processor types.
My alternate proposal was to allow the user to specify a return value for
cpu_speed_func() in gmond.conf that would be used in place of the automatic
detection code. This would require a little more work, but might be a
better solution.
-- Lars
> lars-
>
> what cpu(s) are you running?
> what os?
> what does you /proc/cpuinfo look like (i guess you are running linux)?
> do you have any ideas how the current function is failing to parse it?
>
> sorry there are more questions here than answers.
> - -matt
--
Lars Kellogg-Stedman <[EMAIL PROTECTED]>
Division of Engineering and Applied Sciences
Harvard University
