02-08-2001 10:57 AM
badly) with tusc that as soon as I attach tusc to the process
the CPU consumption of that process drops dramtically.
Apparently tusc serializes the process. Can someone
here tell me exactly what's happening if possible?
The process is multi-threaded.
02-08-2001 12:04 PM
Tusc intercepts all calls from that application, usually making it much slower. When the application performs a task like "malloc", tusc intercepts the call, performs the call for the application, and passes the memory space back to the application. It is supposed to be a middle-man for the application allowing for debugging applications.
Perhaps tusc operates at a low system priority it does not take up as much CPU, but more likely it is because tusc is intercepting all calls, logging each call, then performing the call, and logging the result, then giving the called resource back to the application it does not need that much CPU :)
02-13-2001 12:35 PM
Here's a note about tusc that you might find helpful:
Uses ptrace() and ttrace() (what debuggers use) to gather it's statistics. This was created for HPUX 11 by Chris Bertin.
Strength: As compared to "trace", it prints out a little more useful info with some system calls and is able to trace signals. Kartik's (original author of trace) assessment of tusc as compared to trace: "Tusc is a better program overall than trace. One of its biggest benefits is that tusc can display the contents of buffers passed to system calls, whereas my trace program could not."
Weakness: It is probably as bad as some other tools in it's skewing of timing and possibly program behavior due to the context switching per traced item (with every traced signal and event).
Hope this helps,