Compare Revisions

Debugging Mozilla with Helgrind

Revision 92428:

Revision 92428 by jseward@acm.org on

Revision 92429:

Revision 92429 by jseward@acm.org on

Title:
Debugging Mozilla with Helgrind
Debugging Mozilla with Helgrind
Slug:
Debugging_Mozilla_with_Helgrind
Debugging_Mozilla_with_Helgrind
Content:

Revision 92428
Revision 92429
n61      Hence the first thing to expect is possibly a number of errn61      Hence the first thing to expect is possibly a number of err
>ors that are nothing to do with your code.  You can suppress>ors that are nothing to do with your code.  You can suppress
> these<br>> these in the normal way, by using <code>--gen-suppressions=all</
 >code> and putting the resulting bits of text in a suppression fil
 >e.&nbsp; A bit of time assembling a suppression file for errors t
 >hat seem irrelevant quickly ameliorates this problem.<br>
62      in the normal way, by using <code>--gen-suppressions=all</c
>ode> and putting the resulting bits of text in a suppression file 
>.&nbsp; A bit of time<br> 
63      assembling a suppression file for errors that seem irreleva
>nt quickly ameliorates this problem.<br> 
n65      The second thing to expect is that you won't necessarily gen63      The second thing to expect is that you won't necessarily ge
>t the exactly same set of error reports from identical runs -- yo>t the exactly same set of error reports from identical runs -- yo
>u might,<br>>u might, or you might not.&nbsp; Helgrind uses a race detection a
 >lgorithm which is unfortunately scheduling sensitive, and multipl
 >e identical runs produce overlapping subsets of the full set of d
 >etectable races.<br>
66      or you might not.&nbsp; Helgrind uses a race detection algo
>rithm which is unfortunately scheduling sensitive, and multiple i 
>dentical<br> 
67      runs produce overlapping subsets of the full set of detecta
>ble races.<br> 
n77      You may notice that this development branch of Helgrind pron73      You may notice that this development branch of Helgrind pro
>duces error messages in a different format from the SVN trunk or >duces error messages in a different format from the SVN trunk or 
>3.6.1.<br>>3.6.1.&nbsp; In particular, whenever it shows a stack for a threa
 >d involved in a race, it also shows you the set of locks held by 
 >the thread at that point.&nbsp; This makes it much easier to reas
 >on about who held what lock when, whether two threads agreed on t
 >he lock to use, etc.<br>
78      In particular, whenever it shows a stack for a thread invol
>ved in a race, it also shows you the set of locks held by the thr 
>ead<br> 
79      at that point.&nbsp; This makes it much easier to reason ab
>out who held what lock when, whether two threads agreed on the lo 
>ck<br> 
80      to use, etc.<br>
n82      This branch can also report races where one thread accessesn75      This branch can also report races where one thread accesses
> heap memory whilst another one frees it, and there is no synchro> heap memory whilst another one frees it, and there is no synchro
>nisation<br>>nisation event to guarantee that the access happens before the fr
 >ee.&nbsp; This is disabled by default.&nbsp; <code>--free-is-writ
 >e=yes</code> enables it.
83      event to guarantee that the access happens before the free.
>&nbsp; This is disabled by default.&nbsp; <code>--free-is-write=y 
>es</code> enables it. 
n91      A useful way to approach the resource problem is to differen83      A useful way to approach the resource problem is to differe
>ntiate the activities of (1) detecting the presence of a race fro>ntiate the activities of (1) detecting the presence of a race fro
>m (2)<br>>m (2) collecting enough information to diagnose the cause of a ra
 >ce.&nbsp; (1) is what we need to do when checking code for races,
 > and when verifying that a proposed patch really does fix a race.
 >&nbsp; (2) is what we need to do when investigating a race report
 >.<br>
92      collecting enough information to diagnose the cause of a ra
>ce.&nbsp; (1) is what we need to do when checking code for races, 
> and when verifying that a proposed patch really does fix a race. 
>&nbsp; (2) is what we need to do when investigating a race report 
>.<br> 
n94      The good news is that (1) is much cheaper than (2).&nbsp; Bn85      The good news is that (1) is much cheaper than (2).&nbsp; B
>y default, Helgrind tries to report both stacks involved in a rac>y default, Helgrind tries to report both stacks involved in a rac
>e.&nbsp; That<br>>e.&nbsp; That&nbsp; is expensive because it means collecting a st
 >ack trace for, in effect, every memory reference, just in case it
 > finds a later memory reference that it races against.&nbsp; It i
 >s nearly impossible to make sense of race reports without having 
 >stack traces for both accesses involved, but reporting those requ
 >ires collecting just such a huge set of backtraces.&nbsp; This is
 > what makes (2) expensive.<br>
95      is expensive because it means collecting a stack trace for,
> in effect, every memory reference, just in case it finds a later 
> memory reference that it races against.&nbsp; It is nearly impos 
>sible to make sense of race reports without having stack traces f 
>or both accesses involved, but reporting those requires collectin 
>g just such a huge set of backtraces.&nbsp; This is what makes (2 
>) expensive.<br> 
n99      When doing (1), use the flag <code>--history-level=none</con89      When doing (1), use the flag <code>--history-level=none</co
>de>.&nbsp; This disables the collection of old backtraces, which >de>.&nbsp; This disables the collection of old backtraces, which 
>easily doubles the speed<br>>easily doubles the speed of Helgrind.&nbsp; It means that Helgrin
 >d can only report a stack for one of the accesses in a race -- th
 >e later observed one -- so you can tell the race is there, but yo
 >u can't tell what it is racing against.<br>
100      of Helgrind.&nbsp; It means that Helgrind can only report a
> stack for one of the accesses in a race -- the later observed on 
>e -- so you<br> 
101      can tell the race is there, but you can't tell what it is r
>acing against.<br> 
t103      When you want to investigate in detail, cut the workload dot91      When you want to investigate in detail, cut the workload do
>wn as much as possible, and then re-enable the history mechanism,>wn as much as possible, and then re-enable the history mechanism,
><br>> either by simply omitting <code>--history-level=none</code>, or 
 >giving the default setting <code>--history-level=full</code>.&nbs
 >p; That should give you both stacks involved in the race.&nbsp; I
 >f it doesn't, you may have to&nbsp; throw even more memory at the
 > problem via the <code>--conflict-cache-size=</code> (try valgrin
 >d <code>--tool=helgrind --help</code> for details).&nbsp; This co
 >ntrols how much historical data Helgrind accumulates.<br>
104      either by simply omitting <code>--history-level=none</code>
>, or giving the default setting <code>--history-level=full</code> 
>.&nbsp; That should give you both<br> 
105      stacks involved in the race.&nbsp; If it doesn't, you may h
>ave to&nbsp; throw even more memory at the problem via the <code> 
>--conflict-cache-size=</code><br> 
106      (try valgrind <code>--tool=helgrind --help</code> for detai
>ls).&nbsp; This controls how much historical data Helgrind accumu 
>lates.<br> 

Back to History