)]}'
{
  "commit": "08fbce31a32d837dbc349cf0896cb73afb3abd88",
  "tree": "37658ec86ab7628e7c02e24522767a4b408da504",
  "parents": [
    "a6f5d77deac91a8d5544c05bd379ab207f1b7578"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Tue Jul 10 15:51:38 2018 -0400"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Tue Jul 10 15:51:38 2018 -0400"
  },
  "message": "Don\u0027t use the electric fence in multithreaded code\n\nThe efence doesn\u0027t work with uthreads.  Efence intercepts malloc() et al.\nWhen a uthread exits, its TLS is cleaned up.  Ultimately, this calls into\nglibc, which calls free() on the TLS region in _dl_deallocate_tls(). That\nregion was allocated with __libc_memalign() in _dl_allocate_tls_storage().\nefence can intercept the free(), but not the _libc function.\n\nPending other changes, we shouldn\u0027t use uthreads and the efence.  One\noption would be to briefly disable the efence.  Another would be to not\nactually free the TLS if the efence is linked in.  Neither are good\noptions.\n\nFor now, we\u0027d like to not crash our utests.  The only code using it was\nutests - some of which would break in a somewhat racy manner.\n\nYou can still link in the efence on demand.  If you do, I\u0027d hack up your\n2LS to have threads sleep forever when they finish (pthread.c, look for the\nstart_routine).\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "eb506405625dc2109435c42801f43c6a030f23d6",
      "old_mode": 33188,
      "old_path": "user/utest/Makefile",
      "new_id": "17089ea61260c2604b48b787cabc2cca99b8d171",
      "new_mode": 33188,
      "new_path": "user/utest/Makefile"
    }
  ]
}