Layer的内存泄露问题分析报告

【问题描述】

home应用在运行monkey测试6个小时候,Native Heap增长到200MB,怀疑内存泄露。

我们可以动过dumpsys查看Native Heap的大小:

$adb shell  dumpsys meminfo com.miui.home
Applications Memory Usage (kB):
Uptime: 12929068 Realtime: 12929060

** MEMINFO in pid 1393 [com.miui.home] **
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap        0        0        0        0    16998    16998    19865
  Dalvik Heap    31437    31132        0        0    49618    43555     6063
 Dalvik Other     1164     1164        0        0
        Stack      192      192        0        0
    Other dev     4348     2536        4        0
     .so mmap     1118      360       28        0
    .apk mmap      145        0        0        0
    ...

每个应用的Native Heap占用量都不一样,但一般是10MB量级的,如果超过100MB,那很可能就是泄露了。

【分析步骤】

用monkey脚本复现问题:

adb shell monkey -v -v -p com.miui.home --throttle 200 --pct-touch 20 --pct-motion 25 --pct-nav 20 --pct-majornav 15 --pct-appswitch 5 --pct-anyevent 15 --pct-trackball 0 --pct-syskeys 0 --ignore-crashes --monitor-native-crashes --bugreport 5000000 logcat_file=logcat.txt >log1555.txt

在跑monkey的同时,在手机中运行shell命令,实时查看Native Heap的增长情况:

# while true then
do
date
dumpsys meminfo com.miui.home |grep "Native Heap:"
sleep 60
done

这个脚本的意思是每分钟打印一次当前时间及home应用的Native Heap大小。

跑13个小时后摘出每个小时的Native Heap大小,得出如下列表:

Tue Jan  5 16:12:53 CST 2016
         Native Heap:    13336
Tue Jan  5 17:13:00 CST 2016
         Native Heap:    17256
Tue Jan  5 18:13:35 CST 2016
         Native Heap:    21476
Tue Jan  5 19:13:09 CST 2016
         Native Heap:    25836
Tue Jan  5 20:13:56 CST 2016me
         Native Heap:    30176
Tue Jan  5 21:13:31 CST 2016
         Native Heap:    34836
Tue Jan  5 22:13:07 CST 2016
         Native Heap:    38564
Tue Jan  5 23:13:44 CST 2016
         Native Heap:    42948
Wed Jan  6 00:13:20 CST 2016
         Native Heap:    47216
Wed Jan  6 01:13:57 CST 2016
         Native Heap:    50720
Wed Jan  6 02:14:34 CST 2016
         Native Heap:    55288
Wed Jan  6 03:14:11 CST 2016
         Native Heap:    59360
Wed Jan  6 04:14:49 CST 2016
         Native Heap:    63648
Wed Jan  6 05:15:26 CST 2016
         Native Heap:    67648
Wed Jan  6 05:39:41 CST 2016
         Native Heap:    69440

从上面列表可以看出Native Heap在稳步增长,由此可以看出,确实存在泄露。

而且可以判断可能是基础模块、基础操作有泄露,很可能手动测试就能测出。

将shell脚本的sleep时间缩短为10秒,然后手动操作home界面,发现每次滑动屏幕作左右屏切换时,就会泄露。

进一步通过多种尝试,发现是桌面上存在文件夹图标时,每次左右滑动屏幕必现泄露,而只有应用图标时,则不会泄露。

有了必现路径以后,就可以加log调试了。

libc的malloc有debug功能,只需要改如下代码:

// The value of libc.debug.malloc.
#if !defined(LIBC_STATIC)
static int g_malloc_debug_level = 2;  /*0;*/
#endif

将g_malloc_debug_level从0改成2后,重新生成libc.so和libc_malloc_debug_leak.so后push到手机并重启。

重启后系统中的malloc就会是带有debug功能的malloc了,有啥区别呢?代码如下:

extern "C" void* leak_malloc(size_t bytes) {
    if (DebugCallsDisabled()) {
        return g_malloc_dispatch->malloc(bytes);
    }

    // allocate enough space infront of the allocation to store the pointer for
    // the alloc structure. This will making free‘ing the structer really fast!

    // 1. allocate enough memory and include our header
    // 2. set the base pointer to be right after our header

    size_t size = bytes + sizeof(AllocationEntry);
    if (size < bytes) { // Overflow.
        errno = ENOMEM;
        return NULL;
    }

    void* base = g_malloc_dispatch->malloc(size);
    if (base != NULL) {
        uintptr_t backtrace[BACKTRACE_SIZE];
        size_t numEntries = GET_BACKTRACE(backtrace, BACKTRACE_SIZE);

        AllocationEntry* header = reinterpret_cast<AllocationEntry*>(base);
        header->entry = record_backtrace(backtrace, numEntries, bytes);
        header->guard = GUARD;

        // now increment base to point to after our header.
        // this should just work since our header is 8 bytes.
        base = reinterpret_cast<AllocationEntry*>(base) + 1;
    }

    return base;
}

从代码中可以看出,memleak版本的malloc,再申请内存的时候,会保存当前调用栈。

也就是说每一个malloc都会对应一个调用栈,这样我们后续就可以知道泄露的内存是从哪段代码里申请的。

但这种方式有一个问题,就是保存调用栈本身很消耗内存和CPU资源。

而我们系统中malloc/free的调用是非常频繁(每分钟几十万次)的,

所以打开这个debug功能后,系统会非常卡,甚至会出现ANR等一系列系统问题。

所以这个debug功能的实用性不是很强。

好在我们这个问题有必现路径,所以不需要运行太长时间。

打开调试开关,链接eclipse,操作home几分钟后用ddms的native heap的dump功能,

查出有一个从libhwui.so调用的malloc占用的特别多。

但程序无法运行太长时间,加上调用栈和so对不上(不知道什么原因),所以只能怀疑是这个libhwui.so库有泄露。

我们关注的只是home应用,而打开libc的debug开关后,会影响系统里的所有进程,所以这种调试方式有很多不必要的资源浪费。

好在我们有INJECT工具,可以只针对特定的进程加调试code。

关于INJECT:

1、每个进程都会共享so库的code段,但数据段是各自有一个备份。

比如应用A和应用B都会共享libc的malloc函数,但g_malloc_debug_level变量,他们有各自的一个备份。

2、每个模块调用外部模块的函数时,会从一个叫got表的数据区取得目标函数的地址,然后跳转过去的。

got表的每个表项都存有一个外部函数的地址,是一一对应的。而进程启动过程中linker加载动态库时,为每个动态库填写他们的got表。

比如libandroid_runtime.so和libcutils.so都有各自的got表,got表中对应malloc函数的表项里存放有malloc函数的实际地址。

malloc函数的实际地址是linker加载libc.so后确定的,然后再加载libcutils.so时,将malloc函数的实际地址值填写到libc.so的got表中,malloc对应的表项里。

3、修改代码会影响系统中所有进程,但修改got表只影响单个进程。甚至只影响单个进程的单个模块。

比如我们把A进程的libcutils.so的got表中malloc函数的跳转地址改掉,那只会影响libcutils.so中调用的malloc,libandroid_runtime.so中调用的malloc则不会受影响。

4、我们可以自己定义一个inject_malloc,里面可以加一些调试code,如打印LR寄存器,打印调用栈等,然后再调用malloc。

如:

extern "C" void* inject_malloc(size_t bytes){
    GET_LINK_REGISTER(_lr);
    void* ptr;
    ptr = malloc(bytes);
    LOGD("malloc ptr=%p,size=%08lld,lr=%p",ptr,(unsigned long long)bytes,(void*)_lr);
    return ptr;
}

extern "C" void inject_free(void* p){
    if(p) {
        LOGD("free   ptr=%p",p);
    }
    free(p);
}

由于还不能确定到底是哪个so库泄露,

所以先将home应用加载的所有so库的got表中的malloc和free的跳转地址,改成自定义的inject_malloc/inject_free,

并在自定义的函数里打印如上的LOG,其中malloc函数中,除了要打印buffer地址和大小外,还会打印LR寄存器的值。

这样我们就能确定是从哪个库里调用了malloc。

...
36037:01-07 10:11:25.662  9388  9437 D INJECT  : malloc ptr=0xa7e84800,size=00008196,lr=0xb5d9260d
36038:01-07 10:11:25.663  9388  9437 D INJECT  : free   ptr=0x9934fc00
36041:01-07 10:11:25.664  9388  9388 D INJECT  : malloc ptr=0x99372c00,size=00004100,lr=0xb5d926af
36044:01-07 10:11:25.668  9388  9388 D INJECT  : malloc ptr=0x99376400,size=00004100,lr=0xb5d926af
36053:01-07 10:11:25.669  9388  9437 D INJECT  : free   ptr=0xa7e84800
36064:01-07 10:11:25.684  9388  9437 D INJECT  : free   ptr=0x99377800
36093:01-07 10:11:25.703  9388  9437 D INJECT  : free   ptr=0x9936f000
36132:01-07 10:11:25.726  9388  9437 D INJECT  : free   ptr=0x99378c00
36165:01-07 10:11:25.748  9388  9437 D INJECT  : free   ptr=0x99298800
36198:01-07 10:11:25.767  9388  9437 D INJECT  : malloc ptr=0x99298800,size=00004100,lr=0xb5d926af
36208:01-07 10:11:25.782  9388  9437 D INJECT  : malloc ptr=0xa7e84800,size=00008196,lr=0xb5d9260d
...

复现问题,得到如上的log后除去成对出现的malloc和free,如上面的红色部分。

这样剩下的只有malloc,没有free的就是泄露的buffer了。

虽然只有home应用打印log,但数据两还是很庞大的,得用脚本或程序解析这个log。

我这里是用程序解析,解析后的结论是,95%以上没free的malloc都有如下共同点:

1、size大小为4100,

2、LR为0xb5d926af

通过map表,可以查到0xb5d926af是libhwui.so的code段,因此确定libhwui.so中有泄露。

下一步INJECT只需要修改libhwui.so的malloc/free对应的跳转地址即可。

由于log量进一步减少,所以我们可以在malloc/free时多加一些调试code,比如调用栈:

extern "C" void* inject_malloc(size_t bytes){
    GET_LINK_REGISTER(_lr);
    void* ptr;
    ptr = malloc(bytes);
    LOGD("malloc ptr=%p,size=%08lld,lr=%p",ptr,(unsigned long long)bytes,(void*)_lr);
    if(bytes == 4100) {
         android::CallStack stack(LOG_TAG,3);
    }
    return ptr;
}

同样,利用解析程序可以得出泄露时候的调用栈如下:

01-07 15:32:14.108 12058 12091 D INJECT  : malloc ptr=0xa9948400,size=00004100,lr=0xb5d926af
01-07 15:32:14.122 12058 12091 D INJECT  : #00 pc 00052905  /system/lib/libhwui.so
01-07 15:32:14.122 12058 12091 D INJECT  : #01 pc 00039b2f  /system/lib/libhwui.so
01-07 15:32:14.122 12058 12091 D INJECT  : #02 pc 0003d7f1  /system/lib/libhwui.so
01-07 15:32:14.122 12058 12091 D INJECT  : #03 pc 0001a761  /system/lib/libhwui.so
01-07 15:32:14.122 12058 12091 D INJECT  : #04 pc 0001c3ef  /system/lib/libhwui.so
01-07 15:32:14.122 12058 12091 D INJECT  : #05 pc 0001f3d5  /system/lib/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+80)
01-07 15:32:14.122 12058 12091 D INJECT  : #06 pc 0001006d  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112)
01-07 15:32:14.122 12058 12091 D INJECT  : #07 pc 0005fa87  /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+70)
01-07 15:32:14.122 12058 12091 D INJECT  : #08 pc 0003f4cf  /system/lib/libc.so (__pthread_start(void*)+30)
01-07 15:32:14.122 12058 12091 D INJECT  : #09 pc 00019c2b  /system/lib/libc.so (__start_thread+6)

用addr2line解析:

#0层

$ addr2line -f -e libhwui.so 00052905
_ZN7android10uirenderer13DisplayListOpnwEjRNS0_15LinearAllocatorE
frameworks/base/libs/hwui/DisplayListOp.h:67

对应源码:

class DisplayListOp {
public:
    // These objects should always be allocated with a LinearAllocator, and never destroyed/deleted.
    // standard new() intentionally not implemented, and delete/deconstructor should never be used.
    virtual ~DisplayListOp() { LOG_ALWAYS_FATAL("Destructor not supported"); }
    static void operator delete(void* ptr) { LOG_ALWAYS_FATAL("delete not supported"); }
    static void* operator new(size_t size) = delete; /** PURPOSELY OMITTED **/
    static void* operator new(size_t size, LinearAllocator& allocator) {
        return allocator.alloc(size);
    }

#1层

$ addr2line -f -e libhwui.so 00039b2f
_ZN7android10uirenderer5Layer5deferERKNS0_14OpenGLRendererE
frameworks/base/libs/hwui/Layer.cpp:246 (discriminator 1)

对应源码:

void Layer::defer(const OpenGLRenderer& rootRenderer) {
    ATRACE_LAYER_WORK("Optimize");

    updateLightPosFromRenderer(rootRenderer);
    const float width = layer.getWidth();
    const float height = layer.getHeight();

    if (dirtyRect.isEmpty() || (dirtyRect.left <= 0 && dirtyRect.top <= 0 &&
            dirtyRect.right >= width && dirtyRect.bottom >= height)) {
        dirtyRect.set(0, 0, width, height);
    }

    deferredList.reset(new DeferredDisplayList(dirtyRect));

    DeferStateStruct deferredState(*deferredList, *renderer,
            RenderNode::kReplayFlag_ClipChildren);

    renderer->setViewport(width, height);
    renderer->setupFrameState(dirtyRect.left, dirtyRect.top,
            dirtyRect.right, dirtyRect.bottom, !isBlend());

    renderNode->computeOrdering();
    renderNode->defer(deferredState, 0);

    deferredUpdateScheduled = false;
}

#2层:

$ addr2line -f -e libhwui.so 0003d7f1
_ZN7android10uirenderer14OpenGLRenderer11updateLayerEPNS0_5LayerEb
frameworks/base/libs/hwui/OpenGLRenderer.cpp:389

对应源码:

bool OpenGLRenderer::updateLayer(Layer* layer, bool inFrame) {
    if (layer->deferredUpdateScheduled && layer->renderer
            && layer->renderNode.get() && layer->renderNode->isRenderable()) {

        if (inFrame) {
            endTiling();
            debugOverdraw(false, false);
        }

        if (CC_UNLIKELY(inFrame || Properties::drawDeferDisabled)) {
            layer->render(*this);
        } else {
            layer->defer(*this);
        }

        if (inFrame) {
            resumeAfterLayer();
            startTilingCurrentClip();
        }

        layer->debugDrawUpdate = Properties::debugLayersUpdates;
        layer->hasDrawnSinceUpdate = false;

        return true;
    }

    return false;
}

这里的malloc比较特殊,hwui模块自定义了内存管理模块LinearAllocator,泄露的内存就是通过这个类来管理的。

接下来就是得研究这部分代码了。

首先了解一下alloc过程:

我们从调用栈可以看到#1层的renderNode->defer()到#0层的allocator.alloc(size),

中间丢了很多细节。这主要是因为很多中间函数被内联展开了,所以不会在调用栈中体现。

class Layer : public VirtualLightRefBase {
public:
    ...
    sp<RenderNode> renderNode;

因此renderNode->defer()就会调用下面的函数:

void RenderNode::defer(DeferStateStruct& deferStruct, const int level) {
    DeferOperationHandler handler(deferStruct, level);
    issueOperations<DeferOperationHandler>(deferStruct.mRenderer, handler);
} 

template <class T>
void RenderNode::issueOperations(OpenGLRenderer& renderer, T& handler) {
    ...
    LinearAllocator& alloc = handler.allocator();
    int restoreTo = renderer.getSaveCount();
    handler(new (alloc) SaveOp(SkCanvas::kMatrix_SaveFlag | SkCanvas::kClip_SaveFlag),
                   PROPERTY_SAVECOUNT, properties().getClipToBounds());
    ...

其中SaveOp是继承自DisplayListOp:

class DisplayListOp {
public:
    ...
    static void* operator new(size_t size, LinearAllocator& allocator) {
        return allocator.alloc(size);
    }

class StateOp : public DisplayListOp {
   ...
class SaveOp : public StateOp {

DispayListOp重载了new操作符,allocator.alloc()相当于

RenderNode::issueOperations()中的handler.allocator().alloc(),

而这个handler是DeferOperationHandler()类对象,它的allocator()定义如下:

class DeferOperationHandler {
public:
    DeferOperationHandler(DeferStateStruct& deferStruct, int level)
        : mDeferStruct(deferStruct), mLevel(level) {}
    ...
    inline LinearAllocator& allocator() { return *(mDeferStruct.mAllocator); }
    ...
};

allocator()是mDeferStruct.mAllocator,而mDeferStruct又是构造函数中的参数。

RenderNode::defer()中调用了DeferOperationHandler()的构造函数,并传入参数deferStruct。

而RenderNode::defer()中的deferStruct又是其上一级函数Layer::defer()中构造并传进来的。

void Layer::defer(const OpenGLRenderer& rootRenderer) {
    ...
    deferredList.reset(new DeferredDisplayList(dirtyRect));

    DeferStateStruct deferredState(*deferredList, *renderer,
            RenderNode::kReplayFlag_ClipChildren);
    ...
    renderNode->defer(deferredState, 0);

现在我们要找deferredState的mAllocator:

struct PlaybackStateStruct {
protected:
    PlaybackStateStruct(OpenGLRenderer& renderer, int replayFlags, LinearAllocator* allocator)
            : mRenderer(renderer)
            , mReplayFlags(replayFlags)
            , mAllocator(allocator) {}
public:
    ...
    LinearAllocator * const mAllocator;
    ...
};
...
struct DeferStateStruct : public PlaybackStateStruct {
    DeferStateStruct(DeferredDisplayList& deferredList, OpenGLRenderer& renderer, int replayFlags)
            : PlaybackStateStruct(renderer, replayFlags, &(deferredList.mAllocator)),
            mDeferredList(deferredList) {}
    DeferredDisplayList& mDeferredList;
};

DeferStateStruct继承自PlaybackStateStruct,

其mAllocator是构造函数中转进来的deferredList的mAllocator。

而这个deferredList就是Layer::defer()中new出来的。

deferredList.reset(new DeferredDisplayList(dirtyRect));

DeferredDisplayList()类的定义及它的mAllocator如下:

class DeferredDisplayList {
public:
    ...
    LinearAllocator mAllocator;
};

注意这里的mAllocator已经不是指针了,这意味着它的构造和析构是构造和析构DeferredDisplayList时被调用的。

自此,绕了一大圈我们找到了#0中return allocator.alloc(size);中的alloctor,它就是DeferredDisplayList中的mAllocator。

继续看LinearAllocator::alloc():

void* LinearAllocator::alloc(size_t size) {
    size = ALIGN(size);
    ...
    ensureNext(size);
    void* ptr = mNext;
    mNext = ((char*)mNext) + size;
    mWastedSpace -= size;
    return ptr;
}

void LinearAllocator::ensureNext(size_t size) {
    if (fitsInCurrentPage(size)) return;
    if (mCurrentPage && mPageSize < MAX_PAGE_SIZE) {
        mPageSize = min(MAX_PAGE_SIZE, mPageSize * 2);
        mPageSize = ALIGN(mPageSize);
    }
    mWastedSpace += mPageSize;
    Page* p = newPage(mPageSize);
    if (mCurrentPage) {
        mCurrentPage->setNext(p);
    }
    mCurrentPage = p;
    if (!mPages) {
        mPages = mCurrentPage;
    }
    mNext = start(mCurrentPage);
}

LinearAllocator::Page* LinearAllocator::newPage(size_t pageSize) {
    pageSize = ALIGN(pageSize + sizeof(LinearAllocator::Page));
    ...
    void* buf = malloc(pageSize);    // <<<<这里申请内存
    return new (buf) Page();
}

LinearAllocator::LinearAllocator()
    : mPageSize(INITIAL_PAGE_SIZE)
    ...
    , mDedicatedPageCount(0) {}

mPageSize的初始值INITIAL_PAGE_SIZE是4096,

所以newPage中加上LinearAllocator::Page的大小后,最终pageSized大小就是4100,这与前面得出的结论是一致的。

关于LinearAllocator:

LinearAllocator是管理hwui模块的内存管理单元,由于hwui频繁申请和释放小字节的对象,

如果每个对象都用系统的malloc,则会增加内存碎片并降低效率,所以这里就用内存池管理这些小内存。

第一次申请时先从用malloc向系统申请4KB的堆内存作为内存池(Page类),

后面申请的小内存都从这个内存池里拿(fitsInCurrentPage()就是做这事情的)。

当这个4KB的内存池满了以后,它会再次调用malloc申请8KB的内存,然后将这个作为新的内存池,加入到内存池链表中。

这样的做法有个限制,就是不方便释放。

因为如果要释放内存,我们还得用额外的机制来管理这些释放的内存,这样会增加模块复杂度,效率也会降低。

所以LinearAllocator的做法是,当LinearAllocator析构时,才将内存池链表里的内存给释放掉。如:

LinearAllocator::~LinearAllocator(void) {
    while (mDtorList) {
        auto node = mDtorList;
        mDtorList = node->next;
        node->dtor(node->addr);
    }
    Page* p = mPages;
    while (p) {
        Page* next = p->next();
        p->~Page();
        free(p);                                              // <<<<这里释放内存
        RM_ALLOCATION(mPageSize);
        p = next;
    }
}

如果这里有内存泄露,只有两种可能性

1、内存池一直在涨,LinearAllocator不会被析构

2、LinearAllocator本身有泄露,也就是只有构造,没有析构。

在ensureNext()里调用newPage()之前将mPageSize的大小打印出来,

发现绝大部分mPageSize的size是4096,偶尔会有一两个8192,因此可以判断LinearAllocator有泄露。

我只需要在LinearAllocator的构造和析构函数里打印log,看是否成对出现就可以了。

复测的结果确定是LinearAllocator对象有泄露,

又LinearAllocator是DeferredDisplayList的成员,可以判断DeferredDisplayList对象泄露了。

用同样的方法,很容易确定DeferredDisplayList对象有泄露。

在DeferredDisplayList的构造和析构函数里打印调用栈,

发现都是指向Layer::defer()中的deferredList.reset(new DeferredDisplayList(dirtyRect)):

void Layer::defer(const OpenGLRenderer& rootRenderer) {
    ...
    deferredList.reset(new DeferredDisplayList(dirtyRect));   //<<<<<<

    DeferStateStruct deferredState(*deferredList, *renderer,
            RenderNode::kReplayFlag_ClipChildren);
    ...
    renderNode->defer(deferredState, 0);

构造指向这一行很好理解,为什么析构函数会指向这里呢?

从deferredList的定义可以知道,deferredList是智能指针。

std::unique_ptr<DeferredDisplayList> deferredList;

它的reset()方法会将旧的指针替换为新的指针,并调用旧指针指向的对象的析构函数。如:

  template <typename _Tp, typename _Dp = default_delete<_Tp> >
    class unique_ptr
    {
      ...
      void
      reset(pointer __p = pointer()) noexcept
      {
        using std::swap;
        swap(std::get<0>(_M_t), __p);
        if (__p != pointer())
          get_deleter()(__p);
      }
      ...

从log中我们还可以看到虽然DeferredDisplayList的构造和析构的调用栈都指向同一个地址,但它们并非成对出现。

构造会比析构多很多,也就是说当reset()时deferredList如果指向空指针,这里就不会有析构函数了。

既然不成对出现,那肯定还有别的地方要析构这个DeferredDisplayList对象。而要析构这个对象肯定会用到deferredList。

由于deferredList是private的成员,所以肯定只会在DeferredDisplayList.cpp和DeferredDisplayList.h中会用到。

可疑的代码只有一处:

void Layer::cancelDefer() {
    renderNode = nullptr;
    deferredUpdateScheduled = false;
    deferredList.release();
}

在这里将deferredList指向的指针打印出来,发现只要在这里打出来的地址必定是泄露的。

且deferredList.release()时不会调用DeferredDisplayList()的析构函数。

Layer::defer()和Layer::cancelDefer()代码上是挨着写的,

既然Layer::defer()里会申请内存,那Layer::cancelDefer()里应该会释放内存。

难道作者对智能指针的理解有误?首先从代码角度确定release()确实不会调用析构函数。

      pointer
      release() noexcept
      {
        pointer __p = get();
        std::get<0>(_M_t) = pointer();
        return __p;
      }

显然,这里确实不存在析构。

为此在cancelDefer()里加上deferredList.reset(0);

void Layer::cancelDefer() {
    renderNode = nullptr;
    deferredUpdateScheduled = false;
    deferredList.reset(0);
    deferredList.release();
}

重新编译libhwui.so,push后重启手机,反复滑动桌面,泄露现象不再了。

这样基本上就能确定问题了。应该是原生问题。

从git log中发现这段code是14年底时候在M上加上去的。L的deferredList是普通指针。修改记录如下:

diff --git a/libs/hwui/Layer.h b/libs/hwui/Layer.h
-    DeferredDisplayList* deferredList;
+    std::unique_ptr<DeferredDisplayList> deferredList;

diff --git a/libs/hwui/Layer.cpp b/libs/hwui/Layer.cpp
void Layer::cancelDefer() {
     renderNode = NULL;
     deferredUpdateScheduled = false;
-    if (deferredList) {
-        delete deferredList;
-        deferredList = NULL;
-    }
+    deferredList.release();
}

用L试了下确实没泄露,只有M的机型包括NEXUS也有泄露。

接着给根据提交记录找到google工程师的邮箱,发邮件反馈的一下。

没过10分钟就收到回复说这个问题已经解决,并提供了path。

【解决方案】

diff --git a/libs/hwui/Layer.cpp b/libs/hwui/Layer.cpp
void Layer::cancelDefer() {
     renderNode = NULL;
     deferredUpdateScheduled = false;
-    deferredList.release();
+   deferredList.reset(nullptr);
}

该修改是1个月前提交的,还是比google工程师晚了一步!

时间: 2024-11-02 20:03:47

Layer的内存泄露问题分析报告的相关文章

c/c++服务器程序内存泄露问题分析及解决

由 www.169it.com 搜集整理 对于一个c/c++程序员来说,内存泄漏是一个常见的也是令人头疼的问题.已经有许多技术被研究出来以应对这个问题,比如 Smart Pointer,Garbage Collection等.Smart Pointer技术比较成熟,STL中已经包含支持Smart Pointer的class,但是它的使用似乎并不广泛,而且它也不能解决所有的问题:Garbage Collection技术在Java中已经比较成熟,但是在c/c++领域的发展并不顺畅,虽然很早就有人思考

Android内存泄露案例分析

一款优秀的Android应用,不仅要有完善的功能,也要有良好的体验,而性能是影响体验的一个重要因素.内存泄露是Android开发中常见的性能问题.这篇文章,通过我们曾经遇到的一个真实的案例,来讲述一个内存泄露问题,从发现到分析定位,再到最终解决的全过程. 这里把整个过程分为四个阶段: 第一阶段,现场勘查,分析Bug现象,找出有用线索: 第二阶段,初步推断,根据之前的线索,推断可能导致Bug的原因,并且进一步验证推断是否正确: 第三阶段,探究根源,找出导致Bug的真正原因: 第四阶段,解决方案,研

查看w3wp进程占用的内存及.NET内存泄露,死锁分析

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

ThreadLocal是否会引发内存泄露的分析(转)

这篇文章,主要解决一下疑惑: 1. ThreadLocal.ThreadLocalMap中提到的弱引用,弱引用究竟会不会被回收? 2. 弱引用什么情况下回收? 3. JAVA的ThreadLocal和在什么情况下会内存泄露? 带着这些疑问,自己模拟了一下ThreadLocal.ThreadLocalMap的结构,先展示下自己涉及的结构: 自己实现一个simple的ThreadLocalMap,里面用一个entry用来存放由自己模拟的ThreadLocal调用set方法set进去的值. 并且和JD

查看w3wp进程占用的内存及.NET内存泄露,死锁分析--转载

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

Java 程序的内存泄露问题分析

什么是内存泄露? 广义的Memory Leak:应用占用了内存,但是不再使用(包括不能使用)该部分内存 狭义的Memory Leak:应用分配了内存,但是不能再获取该部分内存的引用(对于Java,也不能被GC) 一个具体的例子: 应用创建了一个长时间运行的Thread 该Thread使用ClassLoader(可以是定制的也可以是默认的)加载了一个类 这个类有一个Static域,指向了一大块内存,然后该Thread的ThreadLocal变量保存了这个类的引用. 最后该Thread清理了对所有已

Android中使用Handler造成内存泄露的分析和解决

什么是内存泄露? Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收.也就是说,一个对象不被任何引用所指向,则该对象会在被GC发现的时候被回收:另外,如果一组对象中只包含互相的引用,而没有来自它们外部的引用(例如有两个对象A和B互相持有引用,但没有任何外部对象持有指向A或B的引用),这仍然属于不可到达,同样会被GC回收. Android中使用Handler造成内存泄露的原因 Handler mHand

一个JS内存泄露实例分析

在看JS GC 相关的文章时,好几次看到了下面这个设计出来的例子,比较巧妙,环环相扣. var theThing = null; var replaceThing = function () { var originalThing = theThing; var unused = function () { if (originalThing) console.log("hi"); }; theThing = { longStr: new Array(10000).join('*'),

【C语言】一次内存泄露的分析的记录

今天运行一个程序,程序刚启动时占用内存很小,在运行过程中发现占用的内存会一直增大. 用cat /proc/pid/statm的方式查看发现也确实在一直增大. 而且这个程序移植到另外一个平台后,会直接无法运行. —————————————————————————————————————————— 我不明白为什么,以为哪里内存泄露了,但是这几乎不可能啊,因为我所有的内存分配都是初始化时完成的, 分配了一些pool和queue,在while(1)大循环中根本没有分配内存啊. 我然后用Valgrind工