<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Todd Schiller - developer questions</title><link href="https://toddschiller.com/" rel="alternate"></link><link href="https://toddschiller.com/feeds/tag/developer-questions.atom.xml" rel="self"></link><id>https://toddschiller.com/</id><updated>2014-12-23T00:00:00-05:00</updated><subtitle>Human ✘ Artificial Intelligence</subtitle><entry><title>4 steps to effective development questions and bug reports</title><link href="https://toddschiller.com/blog/bug-reports-development-questions.html" rel="alternate"></link><published>2014-12-23T00:00:00-05:00</published><updated>2014-12-23T00:00:00-05:00</updated><author><name>Todd Schiller</name></author><id>tag:toddschiller.com,2014-12-23:/blog/bug-reports-development-questions.html</id><summary type="html">&lt;p&gt;Library use is common but documentation is scarce. Your ability to
ascertain information quickly about a library can mean the difference between
success and failure in time-sensitive projects.&lt;/p&gt;
&lt;p&gt;There are two cases where interaction with developers is the bottleneck: (1)
reporting a bug, and (2) learning to use a feature …&lt;/p&gt;</summary><content type="html">&lt;p&gt;Library use is common but documentation is scarce. Your ability to
ascertain information quickly about a library can mean the difference between
success and failure in time-sensitive projects.&lt;/p&gt;
&lt;p&gt;There are two cases where interaction with developers is the bottleneck: (1)
reporting a bug, and (2) learning to use a feature. These are actually
two sides of the same coin — in both cases, the role of the
developer is to reconcile the software's intended behavior with its
actual behavior.&lt;/p&gt;
&lt;p&gt;Developers are busy. Communication with developers is
asynchronous. There are often long delays between
responses. Therefore, when contacting developers you should aim to
minimize (1) the number of developer responses required, and (2) the
effort required for a developer to respond.&lt;/p&gt;
&lt;h2&gt;The Developer Interaction Checklist&lt;/h2&gt;
&lt;p&gt;Here is my checklist for effective development questions and bug reports:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;A (high-level) overview of the problem you are trying to solve&lt;/li&gt;
&lt;li&gt;How you tried to solve the problem&lt;/li&gt;
&lt;li&gt;The &lt;em&gt;exact&lt;/em&gt; error you received (and the inputs that resulted in the
error, when possible)&lt;/li&gt;
&lt;li&gt;Your current understanding of the error, and if possible, how
you've already tried to resolve the error (and what you've learned)&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;These steps are effective because they
&lt;a href="https://en.wikipedia.org/wiki/Verification_and_validation"&gt;validate and verify&lt;/a&gt;
the software:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Steps #1 and #2 &lt;strong&gt;validate&lt;/strong&gt;: is the
software supposed to be able to do what I am trying to do? If not, is there
another (or better) way that I can accomplish the goal?&lt;/li&gt;
&lt;li&gt;Steps #3 and #4 &lt;strong&gt;verify&lt;/strong&gt;: how / why isn't the software
doing what it's supposed to do?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In practice, you can often solve a problem yourself by following
these steps. If you can't, you've put the developer in the best
position to &lt;em&gt;quickly&lt;/em&gt; address the problem with their unique knowledge.&lt;/p&gt;
&lt;h2&gt;Example&lt;/h2&gt;
&lt;p&gt;Here's a question that a colleague and I asked on the
&lt;a href="http://www.dynamorio.org/"&gt;DynamoRIO&lt;/a&gt; mailing list. Can you spot each
of the four steps?&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Is it possible to free memory in the application from a DynamoRIO
client that wraps the free method? We are trying to defer all frees
in the application until another method is called
(pthread_mutex_unlock, in our case), or the thread exits. We're
aware that this breaks transparency, but we still need to do it.
&lt;br /&gt; &lt;br /&gt;
We're currently trying the following: &lt;br /&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Wrap the pre-state of the free(...) method to record the memory
 address in TLS, and then skip the call to the wrapped function&lt;/li&gt;
&lt;li&gt;Wrap the post-state of the pthread_mutex_unlock to perform the
  deferred frees on the recorded memory addresses by calling
  free(...)&lt;/li&gt;
 &lt;/ul&gt;
&lt;p&gt;The free(...) call in the client causes the following error in debug
mode: &lt;br /&gt;&lt;br /&gt;&lt;/p&gt;
&lt;p&gt;&amp;lt;rank order violation dynamo_areas(readwrite)@/src/core/vmareas.c:1544
acquired after global_alloc_lock(recursive)
@/src&amp;gt; /core/heap.c:307 in tid:4ce0&amp;gt; &lt;br /&gt;
&amp;lt;Application test (19669). Internal Error Internal DynamoRIO Error:
/src/core/utils.c:607 (dcontext-&amp;gt;
thread_owned_locks-&amp;gt;last_lock-&amp;gt;rank &amp;lt; lock-&amp;gt;rank
IF_CLIENT_INTERFACE(|| first_client || both_client)) &amp;amp;&amp;amp; &amp;quot;rank
order violation&amp;quot;
... &amp;gt;
&lt;br /&gt; &lt;br /&gt;
, suggesting that the call to free(...) is being passed through an internal
DynamoRIO method which is not re-entrant.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Note how in the email, we're not sure whether or not the behavior
we're seeing is a bug. This is because we're not sure how the software
is supposed to behave!&lt;/p&gt;
&lt;p&gt;Based on this email, the developer was able to quickly get us unstuck
(the same day!) using their unique knowledge:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Most likely your client call to free is a static import and is thus
redirected to DR's heap allocator. A workaround is to call free in
some way other than via a static import. Note that technically
there are deadlock risks with acquiring application locks while in a
DR or client context. &lt;br /&gt; &lt;br /&gt;
Xref two relevant feature requests:&lt;br/&gt;
&lt;a href="http://code.google.com/p/dynamorio/issues/detail?id=497"&gt;http://code.google.com/p/dynamorio/issues/detail?id=497&lt;/a&gt; &lt;br/&gt;
&lt;a href="http://code.google.com/p/dynamorio/issues/detail?id=758"&gt;http://code.google.com/p/dynamorio/issues/detail?id=758&lt;/a&gt; &lt;br/&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2&gt;Summary&lt;/h2&gt;
&lt;p&gt;You can make your interactions with developers more effective by
including the information that best clarifies: (1) what the software is
supposed to do, and (2) why / how / when the software doesn't do what
it's supposed to.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;This post was inspired by my friend Adrian Sampson's
&lt;a href="http://homes.cs.washington.edu/~asampson/blog/bugrubric.html"&gt;Grading Rubric for Bug Reports.&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;
&lt;style&gt;
    blockquote p {
		font-size: 1em;
	}

    li {
		margin-bottom: 1em;
	}

	blockquote li {
		font-size: 1em;
	}
&lt;/style&gt;
</content><category term="Software Engineering"></category><category term="bug reports"></category><category term="technical questions"></category><category term="developer questions"></category><category term="checklist"></category></entry></feed>