)]}'
{
  "commit": "52e4a6cfac46163658bd4f123c49b6ee7dc75f78",
  "tree": "8ce7d8a6597f99d5f72cf0a0071673b2c21d6f01",
  "parents": [
    "20500e2abd0d1f4564a499e83d11d6c73cd58c27"
  ],
  "author": {
    "name": "Jamie Wilkinson",
    "email": "jaq@spacepants.org",
    "time": "Tue Sep 20 07:01:14 2016 +1000"
  },
  "committer": {
    "name": "Bjørn Erik Pedersen",
    "email": "bjorn.erik.pedersen@gmail.com",
    "time": "Mon Sep 19 23:01:14 2016 +0200"
  },
  "message": "Fixes a pass-by-value error in FileData.Name()\n\nFixes a pass-by-value error in FileData.Name() which causes the mutex to be copied, and use that method to retrieve the name of the file from a mem.File.  This really fixes the data race that motivated PR #95. (#96)\r\n\r\nI can\u0027t explain why moving the lock improves the situation, nor why calling through the accessor Name() instead of locking and reading f.fileData.name is not the same, but go vet indicates that the mutex in fileData was being copied, not preserved.\r\n\r\nThe reproducing test case upstream is:\r\ncheck out github.com/google/mtail\r\nmake install_deps\r\ngo test -race -timeout 1m -v -run TestProcessEvents --count\u003d10000 ./vm\r\n\r\nPrior to this change, the test reports a data race 3 times out of 10000, after, 0 times consistently.",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9096ff0af03777ab6658f9977bf29740bd4738e5",
      "old_mode": 33188,
      "old_path": "mem/file.go",
      "new_id": "3c1e09ad1e3f2d50bb28b639717b88b9e717da15",
      "new_mode": 33188,
      "new_path": "mem/file.go"
    },
    {
      "type": "modify",
      "old_id": "44d525ba96bff9bb4ebf3852493bd0e45baec9a7",
      "old_mode": 33188,
      "old_path": "memmap_test.go",
      "new_id": "9efd1f2af9a347f56b36c8c64d9e028d45a01e82",
      "new_mode": 33188,
      "new_path": "memmap_test.go"
    }
  ]
}
