<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Hack MySQL Blog &#187; debugging</title>
	<atom:link href="http://hackmysql.com/blog/tag/debugging/feed/" rel="self" type="application/rss+xml" />
	<link>http://hackmysql.com/blog</link>
	<description></description>
	<lastBuildDate>Fri, 27 Jan 2012 00:00:41 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Debugging and ripple effects</title>
		<link>http://hackmysql.com/blog/2009/11/18/debugging-and-ripple-effects/</link>
		<comments>http://hackmysql.com/blog/2009/11/18/debugging-and-ripple-effects/#comments</comments>
		<pubDate>Wed, 18 Nov 2009 22:58:01 +0000</pubDate>
		<dc:creator>Daniel Nichter</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[debugging]]></category>
		<category><![CDATA[mk-query-digest]]></category>

		<guid isPermaLink="false">http://hackmysql.com/blog/?p=92</guid>
		<description><![CDATA[Like I said earlier, every tiny change that the test suite reveals after code changes is significant. I caught a very subtle &#8220;bug&#8221; today in recent changes to mk-query-digest (a.k.a. mqd). If you like to read about subtle bugs, read on. An mqd test on sample file slow023.txt began to differ after some pretty extensive [...]]]></description>
			<content:encoded><![CDATA[<p>Like I <a href="http://hackmysql.com/blog/2009/10/30/zero-is-a-big-number/">said earlier</a>, every tiny change that the test suite reveals after code changes is significant.  I caught a very subtle &#8220;bug&#8221; today in recent changes to mk-query-digest (a.k.a. mqd).  If you like to read about subtle bugs, read on.</p>
<p>An mqd test on sample file slow023.txt began to differ after some pretty extensive code changes of late:<br />
<code><br />
< # Query 1: 0 QPS, 0x concurrency, ID 0x8E38374648788E52 at byte 0 ________<br />
---<br />
> # Query 1: 0 QPS, 0x concurrency, ID 0x2CFD93750B99C734 at byte 0 ________<br />
</code><br />
The ID which depends on the query&#8217;s fingerprint has changed.  It&#8217;s very important that we don&#8217;t suddenly change these on users because these IDs are pivotal in trend analyses with mqd&#8217;s <code>--review-history</code> option. First some background info on the recent code changes and then the little story about how I tracked down the source of this change.</p>
<p>mqd internals used to run like this: call parser module (like SlowLogParser) and pass it an array of callbacks which it ran events through.  Now this has changed so there&#8217;s a single, unified pipeline of &#8220;callbacks&#8221; (they&#8217;re technically no longer callbacks).  The first process in the pipeline is usually a parser module which returns each event and then mqd keeps pumping the events through the pipeline (in contrast to before where the parser module did the pumping).  So &#8220;obviously&#8221; this has nothing to do with query fingerprinting or ID making which is done in code that has not changed.  Thus, this &#8220;bug&#8221; was very perplexing at first.</p>
<p>First step: see what value <code>make_checksum()</code>, which makes the query IDs, used to get and gets now by using the Perl debugger:<br />
<code><br />
DB<3> x $item<br />
0  'select count(*) as a from x '<br />
</code><br />
<code><br />
DB<12> x $item<br />
0  'select count(*) as a from x'<br />
</code><br />
The difference is that single trailing space. But why has this space suddenly disappeared in the new (later) rev? Something in <code>fingerprint()</code> must have changed, which is the sub that makes that query.  Use the debugger again to step through <code>fingerprint()</code> while a watch is set on the var:<br />
<code><br />
1574:	   $query =~ s/\A\s+//;                  # Chop off leading whitespace<br />
  DB<6><br />
Watchpoint 0:	$query changed:<br />
    old value:	' select count(*) as A from X<br />
'<br />
    new value:	'select count(*) as A from X<br />
'<br />
QueryRewriter::fingerprint(bin/mk-query-digest:1575):<br />
1575:	   chomp $query;                         # Kill trailing whitespace<br />
  DB<6><br />
QueryRewriter::fingerprint(bin/mk-query-digest:1576):<br />
1576:	   $query =~ tr[ \n\t\r\f][ ]s;          # Collapse whitespace<br />
  DB<6><br />
Watchpoint 0:	$query changed:<br />
    old value:	'select count(*) as A from X<br />
'<br />
    new value:	'select count(*) as A from X '<br />
</code><br />
Notice that the var did not change after the line &#8220;# Kill trailing whitespace&#8221; was executed.  The trailing newline was removed and reduced to a single trailing space when &#8220;# Collapse whitespace&#8221; was executed.  The new rev:<br />
<code><br />
1585:	   $query =~ s/\A\s+//;                  # Chop off leading whitespace<br />
  DB<4><br />
Watchpoint 0:	$query changed:<br />
    old value:	' select count(*) as A from X<br />
'<br />
    new value:	'select count(*) as A from X<br />
'<br />
QueryRewriter::fingerprint(../mk-query-digest:1586):<br />
1586:	   chomp $query;                         # Kill trailing whitespace<br />
  DB<4><br />
Watchpoint 0:	$query changed:<br />
    old value:	'select count(*) as A from X<br />
'<br />
    new value:	'select count(*) as A from X'<br />
</code><br />
Notice how <code>chomp</code> in the new rev removed all trailing whitespace; the result of <code>chomp</code> has changed, but why?  In case you didn&#8217;t know, <code>chomp</code> actually chomps any trailing <code>$INPUT_RECORD_SEPARATOR</code>, not just newlines.  It just so happens that many of the parser modules change <code>$INPUT_RECORD_SEPARATOR</code>.</p>
<p>The root of this subtle but very important change is due to the fact that the parser modules no longer call the pipeline callbacks.  When they did, their changes to <code>$INPUT_RECORD_SEPARATOR</code> were visible to the callbacks, and operations like <code>fingerprint()</code> are part of the callbacks.  Now that they do not, their changes to <code>$INPUT_RECORD_SEPARATOR</code> are &#8220;invisible&#8221; and operations like <code>fingerprint()</code> see a different (i.e. the default) <code>$INPUT_RECORD_SEPARATOR</code>.</p>
<p>Conclusion in brief: an issue of scope at the beginning of mk-query-digest affects <code>chomp</code> causing <code>fingerprint()</code> and <code>make_checksum()</code> to generate different query IDs at the end of the script.</p>
]]></content:encoded>
			<wfw:commentRss>http://hackmysql.com/blog/2009/11/18/debugging-and-ripple-effects/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

