> 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.
