Talk:2006WinterRetreat/ReplayDebugging

From RAD Lab

Revision as of 01:21, 10 January 2006; view current revision
←Older revision | Newer revision→
Jump to: navigation, search

Add comments with the '+' tab above!

Contents

[edit]

Discussion

[edit]

"Debug Mode" considered evil

A comment was just made about how debugging tends to perturb execution. The "never turn it off" philosophy doesn't work for large hard systems. You need an low-level instrumentation technology that works in live (non-debug) systems with little (or no) overhead. "DTrace" in Solaris does exactly this: take a look at it.

[edit]

Comments from the audience

  • Hard part of distributed debugging is figuring out if the system is broken. Timing bugs are really the issue. If I turn on one printf, my linking is all different. Changing the execution profile changes the bugs. Doesn't logging change the system? Is there a probe that doesn't affect the device under test?
  • What is the amount of overhead that is ok? A logic analyzer has 0 overhead. What is the middleground?
  • In video conferencing app, disk is the issue. Multimedia apps are abusive to the whole system. For multimedia, 30% is too much
  • MSN server has always-on registry logging for some people, so there is hope. 100 MB of data on production server per day, so that is a good sign.
  • Think through the cost and benefit of the logging. Let people choose where they want to be on the curve.
    • Can you quantify the benefit of the debugging tool?
  • Maybe you can get a lot of benefit from just logging the routing protocols (the control path, no the data path). Perhaps there are analogies to other areas.
  • The marketplace doesn't value debuggers: GDB hasn't gotten better. Maybe DTrace?
  • Map debugability to a business metric
[edit]

Why does the market not value debuggers?

  • the purchase price of a debugger has been set by the market at zero, <li>therefore no one can make a business out of building a good debugger; <li>no one bug has a cost impact that exceeds the engineering cost of building a good debugger, <li>therefore open source evolution doesn't happen. <li>ie. viewed from the point of view of a developer working on a bug, it's always cheaper to fix the bug by banging rocks together that it is to fix it by upgrading the debugger first </ul>
Retrieved from "http://radlab.cs.berkeley.edu/wiki/Talk:2006WinterRetreat/ReplayDebugging"