<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>ACM Queue - Debugging</title>
    <link>http://queue.acm.org/listing.cfm?item_topic=Debugging&amp;qc_type=topics_list&amp;filter=Debugging&amp;page_title=Debugging&amp;order=desc</link>
    <description />
    <item>
      <title>To Catch a Failure: The Record-and-Replay Approach to Debugging</title>
      <link>http://queue.acm.org/detail.cfm?id=3391621</link>
      <description>When work began at Mozilla on the record-and-replay debugging tool called rr, the goal was to produce a practical, cost-effective, resource-efficient means for capturing low-frequency nondeterministic test failures in the Firefox browser. Much of the engineering effort that followed was invested in making sure the tool could actually deliver on this promise with a minimum of overhead. What was not anticipated, though, was that rr would come to be widely used outside of Mozilla?and not just for sleuthing out elusive failures, but also for regular debugging.</description>
      <category>Debugging</category>
      <pubDate>Sat, 28 Mar 2020 12:26:45 GMT</pubDate>
      <author>Robert O'Callahan, Kyle Huey, Devon O'Dell, Terry Coatta</author>
      <guid isPermaLink="false">3391621</guid>
    </item>
    <item>
      <title>Research for Practice: Tracing and Debugging Distributed Systems; Programming by Examples</title>
      <link>http://queue.acm.org/detail.cfm?id=3074451</link>
      <description>This installment of Research for Practice covers two exciting topics in distributed systems and programming methodology. First, Peter Alvaro takes us on a tour of recent techniques for debugging some of the largest and most complex systems in the world: modern distributed systems and service-oriented architectures. The techniques Peter surveys can shed light on order amid the chaos of distributed call graphs. Second, Sumit Gulwani illustrates how to program without explicitly writing programs, instead synthesizing programs from examples! The techniques Sumit presents allow systems to "learn" a program representation from illustrative examples, allowing nonprogrammer users to create increasingly nontrivial functions such as spreadsheet macros. Both of these selections are well in line with RfP's goal of accessible, practical research; in fact, both contributors have successfully transferred their own research in each area to production, at Netflix and as part of Microsoft Excel. Readers may also find a use case!</description>
      <category>Debugging</category>
      <pubDate>Wed, 29 Mar 2017 11:51:58 GMT</pubDate>
      <author>Peter Alvaro, Sumit Galwani</author>
      <guid isPermaLink="false">3074451</guid>
    </item>
    <item>
      <title>The Debugging Mindset</title>
      <link>http://queue.acm.org/detail.cfm?id=3068754</link>
      <description>Software developers spend 35-50 percent of their time validating and debugging software. The cost of debugging, testing, and verification is estimated to account for 50-75 percent of the total budget of software development projects, amounting to more than $100 billion annually. While tools, languages, and environments have reduced the time spent on individual debugging tasks, they have not significantly reduced the total time spent debugging, nor the cost of doing so. Therefore, a hyperfocus on elimination of bugs during development is counterproductive; programmers should instead embrace debugging as an exercise in problem solving.</description>
      <category>Debugging</category>
      <pubDate>Wed, 22 Mar 2017 13:04:14 GMT</pubDate>
      <author>Devon H. O'Dell</author>
      <guid isPermaLink="false">3068754</guid>
    </item>
    <item>
      <title>Debugging Devices</title>
      <link>http://queue.acm.org/detail.cfm?id=1483103</link>
      <description>I suggest taking a very sharp knife and cutting the board traces at random until the thing either works, or smells funny! I gather you're not asking the same question that led me to use the word changeineer in another column. I figure you have an actually malfunctioning piece of hardware and that you've already sent three previous versions back to the manufacturer, complete with nasty letters containing veiled references to legal action should they continue to send you broken products.</description>
      <category>Debugging</category>
      <pubDate>Thu, 08 Jan 2009 14:10:24 GMT</pubDate>
      <author>George Neville-Neil</author>
      <guid isPermaLink="false">1483103</guid>
    </item>
  </channel>
</rss>

