Back in March last year I spent some time using Valgrind’s Helgrind tool
\nto look for data races in the browser.\u00a0 Data races happen when two
\nthreads access the same piece of memory without any form of
\nsynchronisation (either locking or the use of atomic operations), and at
\nleast one of the accesses is a write.\u00a0 That can lead to all manner of
\ndata structure corruption and crashes.\u00a0 What’s really bad is that such
\nbugs are often nearly impossible to reproduce, because they are timing
\ndependent.\u00a0 They therefore fall into the Very Scary Bugs category, and
\nare something we really want to get rid of by any means possible.
\nBefore release!<\/p>\n
Helgrind is a runtime analysis tool that looks for such races.\u00a0 It is far
\nfrom perfect, but better than nothing.\u00a0 For those familiar with these
\nthings, it’s a pure happens-before race detector capable of showing full
\nstacks for both memory accesses involved in a race.\u00a0 It also checks for
\nlock ordering inconsistencies (a.k.a. potential deadlocks) and various
\nmisuses of the POSIX pthreads API.<\/p>\n
So what happened with Helgrinding the browser?\u00a0 In short, I didn’t get
\nfar.\u00a0 Mostly I just got greyer hair.\u00a0 I had hoped to get the browser
\nHelgrind-clean, in the same way it is now pretty much Memcheck-clean,
\nbut the effort got mired in difficulties:<\/p>\n
So I left it at that, resolving one day to come back and fix the vector
\ntimestamp representations, so as to at least avoid the resource
\nproblems.<\/p>\n
Nothing happened for some months.\u00a0 Then, in December, Paul Biggar wrote And I thought: hmm, maybe I should Helgrindify just the threaded jsshell To work properly, Helgrind needs to see all inter-thread synchronisation Paul’s test runs, or, at least, tries to run, all the Sunspider tests in Then we’re ready to go.<\/p>\n I found a number of races — some expected, some not.\u00a0 The unintended Then there are two which are unintended but probably harmless.\u00a0 In both Then there are races which are intended and, so, presumably harmless, on Finally, there’s one I can’t decide about:<\/p>\n It’s pleasing to have a list of at least some of the observable races in I’m a little concerned about the intended races, eg JSRuntime::gcPoke. Boehm has good presentation which summarises the proposed C++0x memory From a Helgrind-usage point of view, these races are easily suppressed Some background Back in March last year I spent some time using Valgrind’s Helgrind tool to look for data races in the browser.\u00a0 Data races happen when two threads access the same piece of memory without any form of synchronisation … Continue reading<\/a><\/p>\n","protected":false},"author":240,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts\/61"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/users\/240"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/comments?post=61"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts\/61\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/media?parent=61"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/categories?post=61"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/tags?post=61"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\na nice self-contained threaded Javascript test case, bug 619595<\/a>.<\/p>\n
\nrunning Paul’s test.\u00a0 The standalone JS engine is smaller and more
\ntractable than the browser, and I knew that Jason Orendorff had
\nsuccessfully used Helgrind on it earlier in the year.\u00a0 Also, there’s
\nbeen a vast amount of JS engine hackery in the past year, with
\nparticular emphasis on the threading aspects.\u00a0 And 4.0 is coming up
\nfast.\u00a0 So, I thought, now might be a good time to give it a spin.<\/p>\nPreparation<\/h3>\n
\nevents in the program under test.\u00a0 It can do that without help for
\nprograms which use only the POSIX pthreads API.\u00a0 But many programs roll
\ntheir own synchronisation primitives, and since it can’t see those,
\nHelgrind reports huge numbers of races which don’t exist.\u00a0 Both NSPR and
\nthe JS engine do this (eg ThinLocks).\u00a0 A small amount of markup using
\nclient requests (bug 551155<\/a>) provides Helgrind with the information it needs.<\/p>\n
\nparallel.\u00a0 I modified it trivially to make it run up to 10 copies of
\neach test in parallel.\u00a0 This stresses Helgrind to the limit of
\nfeasibility on my machine, but shakes out more races.<\/p>\nResults<\/h3>\n
\nand dangerous-looking ones are:<\/p>\n\n
\n— potential crasher<\/li>\n<\/ul>\n\n
\n— consequences unknown to me, but doesn’t look correct<\/li>\n<\/ul>\n\n
\nelements (bug 609104 comment 3<\/a>)<\/li>\n<\/ul>\n
\ncases each thread initialises a shared data structure to some value
\nwhich never changes after that, so multiple initialisations are harmless:<\/p>\n\n
\n
\nthe following fields:<\/p>\n\n
\n
\n
\n
\n
\n
\nstack — that is, just about everything.\u00a0 I don’t know if I expect
\nthat or not.\u00a0 I would have thought that if one thread is scanning the
\nstack, all the other threads are blocked waiting for it, hence there
\nis no race.\u00a0 So either (1) my understanding is wrong, (2) helgrind
\ndoesn’t see the inter-thread sync events causing other threads to
\nwait, or (3) the stack scanner is borked.\u00a0 I suspect (1) or (2).<\/li>\n<\/ul>\nComments<\/h3>\n
\nthe JS engine, since it provides something to cross-check assumed racey
\nbehaviour against.\u00a0 It’s also good to have found some unintended races
\nbefore release.<\/p>\n
\nMy sketchy understanding of the C++0x draft standard is that accesses to
\nshared locations must be mediated either by locking or by machine-level
\natomic operations.\u00a0 All other shared accesses count as races.\u00a0 C++0x, in
\nthe words of Hans J Boehm<\/a>, ‘guarantees nothing in the event of a data
\nrace.\u00a0 Any program allowing a data race produces “undefined behavior”.’<\/p>\n
\nmodel, at http:\/\/www.hpl.hp.com\/personal\/Hans_Boehm\/misc_slides\/c++mm.pdf<\/a>.
\nSee in particular slides 7, 9 and 11.<\/p>\n
\nby adding client requests to specify that the fields in question should
\nnot be race-checked.\u00a0 But, overall, I still don’t like them: deliberate
\nraces are a hindrance to understandability and to automated checking.<\/p>\n","protected":false},"excerpt":{"rendered":"