Researchers take debugging to the masses (News.com) [LWN.net]

News.com covers researchers at the University of California and Stanford University who have released versions of several open-source software packages modified to send debugging information to a central site. "One key part of the project is ensuring the sampler software doesn't bog down the program; the project's goal was to slow performance only by as much as 5 percent, Liblit said. To avoid this degradation, the sampler software records information only occasionally, based on a randomization scheme. One thing that's recorded every time, though, is whether the program exited properly or crashed."

(Log in to post comments)

how about profile ?

Posted Oct 18, 2003 21:55 UTC (Sat) by johnjones (guest, #5462) [Link]

it does not do much what would be nice would be to profile the programs as well to find
hotspots....

HOTSPOTS (maybe cachegrind) and things like valgrind to find memory leaks would be
nice....

they say -
<i>"
Just before each instrumented application exits, it sends a feedback report up to our
collection server here at Bug Isolation Headquarters. That report includes:

application report:

name, version, and release of the application
type, version, and density of instrumentation used
outcome: exit status returned or fatal signal received

samples report:

list of loaded, instrumented code modules (main application, plugins, etc.)
observed predicate counters for each module

If the program received a fatal signal, then the feedback report also includes crash details:

list of loaded shared libraries at the time of failure
stack trace for each thread at the time of failure
</i>

how about profile ?

Posted Oct 19, 2003 1:40 UTC (Sun) by JoeBuck (subscriber, #2330) [Link]

Gathering valgrind/cachegrind data would conflict with the goal of degrading performance only by 5% or so (valgrind typically causes a 20x slowdown).