On Fri, 28 Jun 2002 12:17:58 Ricardo Campos wrote:

I'm getting a massive CPU leak on 2 related apps. First is GLAME, the other is SWEEP. They both 'do the same thing', that is, they are both progs for processing .wav files.

They both produce 100% cpu usage when I open a .wav in them. I suspect it's not the app itself (2 massively broken apps- I doubt it), but perhaps my audio setup? They both use /dev/dsp, and use audio_in and audio_out for i/p and o/p.

I used the same version of these apps with the same kernel on my Redhat installation on the same box, and don't get the same problem.

I can't think what gets?

One technique you may find useful for this kind of thing is to look at the proportion of CPU time spend in the kernel (sys cpu time) and in user code (user cpu time).

For progs which consume a lot of sys cpu there are a couple of likely possibilities:

1. The program is doing some kind of busy wait deliberately.

2. The program make a system call that it expects to return data, but the call returns failure instead and the program retries the call.

In your example, if a program tries to read from a /dev/dsp device with a loop like:

while ((nbytes = read(fd, buf, size) != 0) if (nbytes > 0) do_something();

then it would exhibit exactly this behaviour.

If the program is using almost exclusively user mode CPU then it would suggest that the program has simpy got into an infinite loop due toa bug in the program.

All this is rather aproximate but may be some help.

Steve.

On Tue, Jul 02, 2002 at 12:39:55AM +0000, MJ Ray said:

I think you can do this by running a multi-part load meter like the one on gkrellm (or top in a terminal). You can also try running the application from the shell with "time" in front, but that only gets reported when the app quits.

Am I thinking of the right thing here?

Run both. That way you can analyse the problem. Gkrellm just gives a monitor on the cpu and various stuff. But it is nice to leave it running to see if the CPU usage stops.