<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: A Very Subtle Bug</title>
	<atom:link href="http://blog.nelhage.com/2010/02/a-very-subtle-bug/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/</link>
	<description>It's software. It's made of bugs.</description>
	<lastBuildDate>Mon, 06 Sep 2010 07:46:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Chris Lesniewski-Laas</title>
		<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/comment-page-1/#comment-595</link>
		<dc:creator>Chris Lesniewski-Laas</dc:creator>
		<pubDate>Thu, 11 Mar 2010 04:33:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nelhage.com/?p=150#comment-595</guid>
		<description>&lt;p&gt;In 6.033, &quot;complex systems fail for complex reasons&quot; does refer to the subtle interactions between components, but it also is meant to serve as a reminder that technical root causes have deeper organizational and societal root causes: the &quot;Keep Digging&quot; principle.&lt;/p&gt;

&lt;p&gt;In fact, the &lt;a href=&quot;http://history.nasa.gov/rogersrep/genindex.htm&quot; rel=&quot;nofollow&quot;&gt;Rogers Report&lt;/a&gt; on the Space Shuttle Challenger disaster is a classic example of the Keep Digging principle.  The Columbia disaster does not have the same classic status, but NASA applied similar thoroughness in &lt;a href=&quot;http://spaceflight.nasa.gov/shuttle/archives/sts-107/investigation/CAIB_medres_full.pdf&quot; rel=&quot;nofollow&quot;&gt;its analysis&lt;/a&gt; of that event.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>In 6.033, &#8220;complex systems fail for complex reasons&#8221; does refer to the subtle interactions between components, but it also is meant to serve as a reminder that technical root causes have deeper organizational and societal root causes: the &#8220;Keep Digging&#8221; principle.</p>

<p>In fact, the <a href="http://history.nasa.gov/rogersrep/genindex.htm" rel="nofollow">Rogers Report</a> on the Space Shuttle Challenger disaster is a classic example of the Keep Digging principle.  The Columbia disaster does not have the same classic status, but NASA applied similar thoroughness in <a href="http://spaceflight.nasa.gov/shuttle/archives/sts-107/investigation/CAIB_medres_full.pdf" rel="nofollow">its analysis</a> of that event.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: tranto</title>
		<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/comment-page-1/#comment-569</link>
		<dc:creator>tranto</dc:creator>
		<pubDate>Tue, 02 Mar 2010 09:51:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nelhage.com/?p=150#comment-569</guid>
		<description>&lt;p&gt;&lt;blockquote cite=&quot;#commentbody-562&quot;&gt;
&lt;strong&gt;&lt;a href=&quot;#comment-562&quot; rel=&quot;nofollow&quot;&gt;nelhage&lt;/a&gt; :&lt;/strong&gt;
&lt;p&gt;The short version is that there’s a race condition — the kernel will buffer some amount of data, so it’s possible for gzip to write the remaining data into the kernel pipe buffer (without tar reading it), and exit before tar closes the pipe, in which case there’s no SIGPIPE.&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Surely this can only succeed with fairly short .tar files then?  I mean, if you want an entry from the beginning or the middle of a large archive, there&#039;s no way the contents following the entry will fit in a pipe buffer.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p><blockquote cite="#commentbody-562">
<strong><a href="#comment-562" rel="nofollow">nelhage</a> :</strong>
<p>The short version is that there’s a race condition — the kernel will buffer some amount of data, so it’s possible for gzip to write the remaining data into the kernel pipe buffer (without tar reading it), and exit before tar closes the pipe, in which case there’s no SIGPIPE.</p></blockquote></p>

<p>Surely this can only succeed with fairly short .tar files then?  I mean, if you want an entry from the beginning or the middle of a large archive, there&#8217;s no way the contents following the entry will fit in a pipe buffer.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: lacos / lbzip2</title>
		<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/comment-page-1/#comment-563</link>
		<dc:creator>lacos / lbzip2</dc:creator>
		<pubDate>Mon, 01 Mar 2010 17:22:16 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nelhage.com/?p=150#comment-563</guid>
		<description>&lt;p&gt;Followup from the GNU tar maintainer &lt;a href=&quot;http://lists.gnu.org/archive/html/help-tar/2010-03/msg00003.html&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Followup from the GNU tar maintainer <a href="http://lists.gnu.org/archive/html/help-tar/2010-03/msg00003.html" rel="nofollow">here</a>.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: nelhage</title>
		<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/comment-page-1/#comment-562</link>
		<dc:creator>nelhage</dc:creator>
		<pubDate>Mon, 01 Mar 2010 15:22:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nelhage.com/?p=150#comment-562</guid>
		<description>&lt;p&gt;The short version is that there&#039;s a race condition -- the kernel will buffer some amount of data, so it&#039;s possible for gzip to write the remaining data into the kernel pipe buffer (without tar reading it), and exit before tar closes the pipe, in which case there&#039;s no SIGPIPE.&lt;/p&gt;

&lt;p&gt;In response to this post and reddit discussion, a friend of mine did some tar source-diving and figured out some more about what&#039;s going on, which you can read &lt;a href=&quot;http://davidben.scripts.mit.edu/blog/2010/02/28/tar-filled-pipes/&quot; rel=&quot;nofollow&quot;&gt;on his blog.&lt;/a&gt;&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>The short version is that there&#8217;s a race condition &#8212; the kernel will buffer some amount of data, so it&#8217;s possible for gzip to write the remaining data into the kernel pipe buffer (without tar reading it), and exit before tar closes the pipe, in which case there&#8217;s no SIGPIPE.</p>

<p>In response to this post and reddit discussion, a friend of mine did some tar source-diving and figured out some more about what&#8217;s going on, which you can read <a href="http://davidben.scripts.mit.edu/blog/2010/02/28/tar-filled-pipes/" rel="nofollow">on his blog.</a></p>]]></content:encoded>
	</item>
	<item>
		<title>By: Thanassis</title>
		<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/comment-page-1/#comment-561</link>
		<dc:creator>Thanassis</dc:creator>
		<pubDate>Mon, 01 Mar 2010 13:24:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nelhage.com/?p=150#comment-561</guid>
		<description>&lt;p&gt;I understand the complex interactions now that you&#039;ve described them - what I don&#039;t understand is how you sometimes have the command succeed, and sometimes fail... With SIGPIPE set to SIG_IGN, shouldn&#039;t you ALWAYS get an EPIPE, and therefore an error at the Python level?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I understand the complex interactions now that you&#8217;ve described them &#8211; what I don&#8217;t understand is how you sometimes have the command succeed, and sometimes fail&#8230; With SIGPIPE set to SIG_IGN, shouldn&#8217;t you ALWAYS get an EPIPE, and therefore an error at the Python level?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: ALB</title>
		<link>http://blog.nelhage.com/2010/02/a-very-subtle-bug/comment-page-1/#comment-553</link>
		<dc:creator>ALB</dc:creator>
		<pubDate>Sun, 28 Feb 2010 09:33:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.nelhage.com/?p=150#comment-553</guid>
		<description>&lt;p&gt;&quot;Complex systems fail for complex reasons.&quot; I agree, this is a quotation that does not accurately capture reality. In fact, complex systems fail for simple reasons. However, the complexity makes it far more difficult to find the simple reason, in part because there are so many possible simple reasons.&lt;/p&gt;

&lt;p&gt;A classic example of this is the Columbia shuttle disaster, in which a simple piece of falling foam doomed the mission.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>&#8220;Complex systems fail for complex reasons.&#8221; I agree, this is a quotation that does not accurately capture reality. In fact, complex systems fail for simple reasons. However, the complexity makes it far more difficult to find the simple reason, in part because there are so many possible simple reasons.</p>

<p>A classic example of this is the Columbia shuttle disaster, in which a simple piece of falling foam doomed the mission.</p>]]></content:encoded>
	</item>
</channel>
</rss>
