[linux-audio-user] gcdmaster

[Malcolm Baldridge]

> Nothing else breaks that badly.

Not knowing the specifics of the code in question, it's possible that
(buggy?) code which burns alot of CPU would show up a heat problem where a
properly functioning program which doesn't sit-and-spin would not.

If you can rebuild your kernel 6 times in a row (make clean ; make bzImage ;
make clean ; make bzImage) etc, without getting a signal 11 from gcc, then
heat's most likely not your problem.  "sensors" will be more scientific
about this.

It's just that 5-10 minutes is a "long time" in code execution time frames. 

Possibilities include:

1) Hardware fault [heat or bad ram]
2) Memory leak [bad or mismatched libraries, or old/mismatched ALSA
libs+drivers?] 

See if you can lengthen the amount of time the program can run by killing
off all but the most necessary background tasks.  If there's a correlation
between runtime and the amount of free memory at the time you run this tool,
then 2) is pretty much your issue.

If you've done some "partial upgrades" of various components, you may want
to look into a "rebuild" of your library infrastructures.

In the end, even Dear Frodo couldn't bear to destroy Quality,

=MB=
-- 
A focus on Quality.