)]}'
{
  "log": [
    {
      "commit": "885f3b9cad01b8158aadc55c159c17dbf34f622c",
      "tree": "55991f909d2a12f185c0773de57cdf01b7074ecd",
      "parents": [
        "b7b4f5b838cd41407c734af74e8211f5c7da0036"
      ],
      "author": {
        "name": "Christopher Ferris",
        "email": "cferris@google.com",
        "time": "Tue May 21 17:48:01 2013 -0700"
      },
      "committer": {
        "name": "Christopher Ferris",
        "email": "cferris@google.com",
        "time": "Fri Jun 07 14:55:32 2013 -0700"
      },
      "message": "Implement malloc_usable_size for debug impls.\n\n- Implemented chk_memalign.\n- Fixed a few bugs in leak_memalign.\n- Implemented {leak,fill,check,qemu}_malloc_usable_size.\n- Make malloc_usable_size update at run time.\n- Add malloc_test.cpp as a small set of tests for the\n  malloc debug routines.\n- Fix the qemu routines since it\u0027s been broken since it moved to C++.\n- Add support for the %u format to the out_vformat in libc_logging.cpp.\n  This is used by the emulator code.\n\nTested using the bionic-unit-tests with setprop libc.debug.malloc\nset to 1, 5, and 10.\n\nI tested as much as possible on the emulator, but tracing doesn\u0027t appear\nto be working properly.\n\nBug: 6143477\n\nMerge change from internal master.\n\n(cherry-picked from commit 3d594c258045783fc9e1956ce7a4d91e302f011e)\n\nChange-Id: I4ae00fffba82315a8c283f35893fd554460722fb\n"
    },
    {
      "commit": "8f2a5a0b40fc82126c691d5c30131d908772aab7",
      "tree": "0b29a5dc82395c076387edb5af9ca271a91264c0",
      "parents": [
        "e23ed8c6441389a79c6504295184f7249e01a197"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Mar 15 15:30:25 2013 -0700"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Mar 15 16:12:58 2013 -0700"
      },
      "message": "Clean up internal libc logging.\n\nWe only need one logging API, and I prefer the one that does no\nallocation and is thus safe to use in any context.\n\nAlso use O_CLOEXEC when opening the /dev/log files.\n\nMove everything logging-related into one header file.\n\nChange-Id: Ic1e3ea8e9b910dc29df351bff6c0aa4db26fbb58\n"
    },
    {
      "commit": "9c81892c2e8c684e0da12028e389bf6d9b5253b7",
      "tree": "a6a5f54863bcf4467ce2cc27d9cf669120b35c39",
      "parents": [
        "1bf835558a3f7424c805766250ace88fa70e0630"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Feb 01 17:07:40 2013 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Feb 01 17:07:40 2013 -0800"
      },
      "message": "Don\u0027t claim there were no leaks if we weren\u0027t even checking.\n\nBug: 8107016\nChange-Id: I9059f1f8374ebcdf00dfc6ac74d3709f501292c9\n"
    },
    {
      "commit": "1d12d574169cedd68185196e4957597d00fd4681",
      "tree": "0da27f2238592c5bb074afe229e97b802ddb6161",
      "parents": [
        "a990cf5b3392c5aef767aee1e67b4d7ef651afc6"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Wed Jan 30 11:38:26 2013 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Wed Jan 30 11:38:26 2013 -0800"
      },
      "message": "Say explicitly if there were no leaks.\n\nOtherwise people trying to use this are left wondering \"did I not leak, or did\nthe leak checking code not get called when I exited?\".\n\nChange-Id: If79b225f8a2e24dd69aba1fb836bf9e81bb00efe\n"
    },
    {
      "commit": "35b621c5f4c79959cd36fec0153c2c9c43ebe5f0",
      "tree": "016d232e99a12943587357bf8b10a3d25cb98b0e",
      "parents": [
        "a0151cbfbaa37965dbcd188a55a78d3ad4802b9b"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Mon Jan 28 16:27:36 2013 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Tue Jan 29 09:56:31 2013 -0800"
      },
      "message": "Don\u0027t collect useless stack frames; do demangle C++ symbols.\n\nPreviously, we\u0027d collect every stack frame and then throw some away\nwhen we came to log them. This meant that stack traces were effectively\nshorter than the buffers that had been allocated for them. This patch\nonly stores frames we\u0027ll actually output.\n\nAlso dynamically call the C++ demangler so we don\u0027t have to try to\nread mangled names. Because no one knows the mangling of operator new[]\nfor int arrays off the top of their head.\n\nBug: 7291287\nChange-Id: I42b022fd7cd61675d05171de4c3b2704d058ef2a\n"
    },
    {
      "commit": "239e7a0756fddf3698bf72cab10d7f382421090b",
      "tree": "6ec3636787883bf1b20bd490cc011110b625d3fe",
      "parents": [
        "6a94cb748bf63278c3271b0ab610061b0dc6f04a"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Jan 25 17:13:45 2013 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Jan 25 17:13:45 2013 -0800"
      },
      "message": "More debug malloc fixes.\n\nInclude the leaky executable\u0027s name in the log output. Fix the \"sh\" test.\nUse uintptr_t instead of intptr_t.\n\nAlso fix debug formatting of NULL with %s.\n\nBug: 7291287\nChange-Id: I015bf341cd48d43a247173612e6ccb1bf1243d53\n"
    },
    {
      "commit": "848247a972038e30e12b0c9f7f049aa97c73b9c7",
      "tree": "baaaa82fff74ab5785e28bf078b30563a90b8290",
      "parents": [
        "28f82b260c9076aae437dafb57193a174aef1eb3"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Tue Jan 22 18:36:28 2013 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Tue Jan 22 18:36:28 2013 -0800"
      },
      "message": "Don\u0027t free anything when reporting leaks.\n\nWe don\u0027t know that they\u0027re not going to be cleaned up by a\nC++ global destructor that runs after us. This is the case with\nbootanimation, for example.\n\nBug: 7291287\nChange-Id: Iba402514d1735fdc2ae4bc95b65396d816be46c0\n"
    },
    {
      "commit": "1e980b6bc8315d00a07312b25486531247abd98c",
      "tree": "539f2c0c63fca27d5eb6ba184d658bb0e11a32d9",
      "parents": [
        "e4ca88d9fa8757e4fb4056fcafa5bc15b406a2fd"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Thu Jan 17 18:36:06 2013 -0800"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Jan 18 22:20:06 2013 -0800"
      },
      "message": "Fix the duplication in the debugging code.\n\nWe had two copies of the backtrace code, and two copies of the\nlibcorkscrew /proc/pid/maps code. This patch gets us down to one.\n\nWe also had hacks so we could log in the malloc debugging code.\nThis patch pulls the non-allocating \"printf\" code out of the\ndynamic linker so everyone can share.\n\nThis patch also makes the leak diagnostics easier to read, and\nmakes it possible to paste them directly into the \u0027stack\u0027 tool (by\nusing relative PCs).\n\nThis patch also fixes the stdio standard stream leak that was\ncausing a leak warning every time tf_daemon ran.\n\nBug: 7291287\nChange-Id: I66e4083ac2c5606c8d2737cb45c8ac8a32c7cfe8\n"
    },
    {
      "commit": "e7e274b13a44a63023f22630ac282ee2e919ffb7",
      "tree": "3f11f7205b678be632e15f013ef0443cf706bab3",
      "parents": [
        "9434e8febc8b223db2d49e7f97140771700113b9"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Oct 12 17:05:05 2012 -0700"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Fri Oct 12 17:05:05 2012 -0700"
      },
      "message": "Fix realloc(3) when chk_malloc debugging is on.\n\nThe tests for a NULL pointer and size 0 were the wrong way round.\n\nFrom Intel\u0027s patch 9cae4f2ffc4778ed82be04711d8775a84092d4e2.\n\nChange-Id: I118aff3358aa5f34126d74bfaa43f6e2f1a89055\n"
    },
    {
      "commit": "3b297c40794b23d50cb5240f9b03f6ef25fd98db",
      "tree": "ebcb95b3cd9f249f08257e8654307f88c98e6dbb",
      "parents": [
        "417fd2334a694cf6a831b81cd672b4ca31ff2f54"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Thu Oct 11 16:08:51 2012 -0700"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Thu Oct 11 16:08:51 2012 -0700"
      },
      "message": "Fix dlerror(3).\n\nAdd unit tests for dlerror(3) in various situations. I think We\u0027re at least\nas good as glibc now.\n\nAlso factor out the ScopedPthreadMutexLock and use it here too.\n\nBug: http://code.google.com/p/android/issues/detail?id\u003d38398\nChange-Id: I040938b4366ab836e3df46d1d8055b92f4ea6ed8\n"
    },
    {
      "commit": "c4d1fecc105063e68a5090a6900b63d1b9a24287",
      "tree": "93dad687b245a981d3c47ede05b43345b86202fe",
      "parents": [
        "9dfaa63a1c0d1b8e75dd9d7077a8103a19821fa9"
      ],
      "author": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Tue Aug 28 14:15:04 2012 -0700"
      },
      "committer": {
        "name": "Elliott Hughes",
        "email": "enh@google.com",
        "time": "Wed Aug 29 12:08:13 2012 -0700"
      },
      "message": "Clean up warnings in the malloc_debug_* files.\n\nAlso clean up cpplint.py-detected lint.\n\nChange-Id: Ia18e89c4c6878764f8d7ed34b8247e7a8d8fe88b\n"
    },
    {
      "commit": "e1dd3c287ba836281de0197670018bd9bbfbd62b",
      "tree": "a5138cb21c8de6be4ea4be61e44f95fb8bcb776e",
      "parents": [
        "7d2e24eb167b6257f7935c7bd2023a708704ca1a"
      ],
      "author": {
        "name": "Iliyan Malchev",
        "email": "malchev@google.com",
        "time": "Tue May 29 14:22:42 2012 -0700"
      },
      "committer": {
        "name": "Iliyan Malchev",
        "email": "malchev@google.com",
        "time": "Fri Jun 01 15:54:34 2012 -0700"
      },
      "message": "bionic: import heaptracker as chk_malloc\n\nThis patch is a rewrite of libc.debug.malloc \u003d 10 (chk_malloc).  It provides\nthe same features as the original (poison freed memory, detect heap overruns\nand underruns), except that it provides more debugging information whenever it\ndetects a problem.\n\nIn addition to the original features, the new chk_malloc() implementation\ndetects multiple frees within a given range of the last N allocations, N being\nconfigurable via the system property libc.debug.malloc.backlog.\n\nFinally, this patch keeps track of all outstanding memory allocations.  On\nprogram exit, we walk that list and report each outstanding allocation.\n\n(There is support (not enabled) for a scanner thread periodically walks over\nthe list of outstanding allocations as well as the backlog of recently-freed\nallocations, checking for heap-usage errors.)\n\nFeature overview:\n\n  1) memory leaks\n  2) multiple frees\n  3) use after free\n  4) overrun\n\nImplementation:\n\n-- for each allocation, there is a:\n  1) stack trace at the time the allocation is made\n  2) if the memory is freed, there is also a stack trace at the point\n  3) a front and rear guard (fence)\n  4) the stack traces are kept together with the allocation\n\n-- the following lists and maintained\n\n  1) all outstanding memory allocations\n  3) a backlog of allocations what are freed; when you call free(), instead of\n     actually freed, the allocation is moved to this backlog;\n  4) when the backlog of allocations gets full, the oldest entry gets evicted\n     from it; at that point, the allocation is checked for overruns or\n     use-after-free errors, and then actually freed.\n  5) when the program exits, the list of outstanding allocations and the\n     backlog are inspected for errors, then freed;\n\nTo use this, set the following system properties before running the process or\nprocesses you want to inspect:\n\nlibc.malloc.debug.backlog # defaults to 100\nlibc.malloc.debug 10\n\nWhen a problem is detected, you will see the following on logcat for a multiple\nfree:\n\nE/libc    ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 BYTES MULTIPLY FREED!\nE/libc    ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 ALLOCATED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c658  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d80  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 4009647c  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\nE/libc    ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 FIRST FREED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c7d2  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d94  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 40096490  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\nE/libc    ( 7233): +++ ALLOCATION 0x404b9278 SIZE 10 NOW BEING FREED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c6ac  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d94  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 400964a0  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\n\nThe following for a heap overrun and underrun:\n\nE/libc    ( 7233): +++ REAR GUARD MISMATCH [10, 11)\nE/libc    ( 7233): +++ ALLOCATION 0x404b9198 SIZE 10 HAS A CORRUPTED REAR GUARD\nE/libc    ( 7233): +++ ALLOCATION 0x404b9198 SIZE 10 ALLOCATED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c658  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d80  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 40096438  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\nE/libc    ( 7233): +++ ALLOCATION 0x404b9198 SIZE 10 FREED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c7d2  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d94  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 40096462  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\nE/libc    ( 7233): +++ ALLOCATION 0x404b9358 SIZE 10 HAS A CORRUPTED FRONT GUARD\nE/libc    ( 7233): +++ ALLOCATION 0x404b9358 SIZE 10 ALLOCATED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c658  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d80  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 400964ba  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\nE/libc    ( 7233): +++ ALLOCATION 0x404b9358 SIZE 10 FREED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c7d2  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d94  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 400964e4  /system/bin/malloctest\nE/libc    ( 7233):      #04  pc 00016f24  /system/lib/libc.so\n\nThe following for a memory leak:\n\nE/libc    ( 7233): +++ THERE ARE 1 LEAKED ALLOCATIONS\nE/libc    ( 7233): +++ DELETING 4096 BYTES OF LEAKED MEMORY AT 0x404b95e8 (1 REMAINING)\nE/libc    ( 7233): +++ ALLOCATION 0x404b95e8 SIZE 4096 ALLOCATED HERE:\nE/libc    ( 7233): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***\nE/libc    ( 7233):      #00  pc 0000c35a  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #01  pc 0000c658  /system/lib/libc_malloc_debug_leak.so\nE/libc    ( 7233):      #02  pc 00016d80  /system/lib/libc.so\nE/libc    ( 7233):      #03  pc 0001bc94  /system/lib/libc.so\nE/libc    ( 7233):      #04  pc 0001edf6  /system/lib/libc.so\nE/libc    ( 7233):      #05  pc 0001b80a  /system/lib/libc.so\nE/libc    ( 7233):      #06  pc 0001c086  /system/lib/libc.so\nE/libc    ( 7233):      #07  pc 40096402  /system/bin/malloctest\nE/libc    ( 7233):      #08  pc 00016f24  /system/lib/libc.so\n\nChange-Id: Ic440e9d05a01e2ea86b25e8998714e88bc2d16e0\nSigned-off-by: Iliyan Malchev \u003cmalchev@google.com\u003e\n"
    }
  ]
}
