Memory leak through IClipboardDataPasteEventImpl

I noticed an odd memory increase in one of my Activities. Hence I ran a little test: I opened the dialog multiple times (open - close - open - close ....) and the memory kept increasing. So I used the DDMS to dump an HPROF file and opened it in MAT (Memory analyzer). The leak suspect report indicated, that the main reason for the growing memory consumption was this:

So I did a histogramm, to check that dialog I ran my tests on and what's keeping it alive. Turns out, it's kept alive by it's AutoCompleteTextViews, which in turn are kept alive by android.widget.TextView$IClipboardDataPasteEventImpl. However there are no immediate dominators for IClipboardDataPasteEventImpl (except of course the GC Root). I tried to find that IClipboardDataPasteEventImpl on the internet and I searched grepcode (the android source), but the only thing I could come up with was this blog entry. I can't read whatever language that is, but what I could read are the English words thrown in, which indicates, that it might be a bug on the Samsung Galaxy SII (the phone I am using, running android 2.3.x), related to the ClipboardManager. However I am unsure of this (I want to fix this, hence I am disinclined to simply accept it to be an unfixable bug) and I have no clue, where this Clipboard is spawned and why. I would greatly appreciate any pointers/ideas on the matter.

回答1:

My memleak investigation also brought me here. Im having problems with Activity leaking over EditText. android.widget.TextView$IClipboardDataPasteEventImpl object is holding the EditText which is holding the activity. This happens on Samsung Galaxy Tab 10.1, and Galaxy Tab 2 10.1, 7.0. I wasn't able to reproduce it on other non Samsung devices (Asus, Acer).

The bad thing is that I didn't find a solution for it yet :)

回答2:

Investigation

Here're my research results:

It happens to any Activity whose content view consists of an EditText. finish()ing the Activity does not get it garbage collected as it is being referenced, like this:

activity com.example.MyActivity
<- mContext android.widget.TextView
    <- this$0 android.widget.TextView$IClipboardDataPasteEventImpl
        <- this$1 android.widget.TextView$IClipboardDataPasteEventImpl$1
            <- referent java.lang.ref.FinalizerReference

It happens on my Samsung Galaxy Tab GT-P7300 running Android 4.0.4, but not on my Samsung Galaxy Mini GT-S5570 running Android 2.2.1.
The IClipboardDataPasteEventImpl objects eventually get freed, actually, but only at times which seems to be unpredictable.

Since they are referenced by java.lang.ref.FinalizerReference, I believe that the IClipboardDataPasteEventImpl objects are waiting to be finalize()'d, which happens only when the JVM feels like to. For details, check out these SO questions:

is memory leak? why java.lang.ref.Finalizer eat so much memory
Very strange OutOfMemoryError

Solution / Workaround

Sorry, no solution, but here's my best workaround:

In onDestroy() of your Activity, free as many references to other objects as possible (especially the big ones, such as bitmaps, collections, and child views of your activity), like this:

@Override
protected void onDestroy()
{
    // Free reference to large objects.
    m_SomeLargeObject = null;
    m_AnotherLargeObject = null;

    // For ArrayList, if you are a paranoid to null, you may call clear() and then trimToSize().
    m_SomeLargeArrayList.clear();
    m_SomeLargeArrayList.trimToSize();

    // Free child views.
    m_MyButton = null;

    // Free adapters.
    m_ListViewAdapter = null;

    ... etc.

    // Don't forget to chain the call to the superclass.
    super.onDestroy();
}

This way, we can at least reduce the casualties and hopefully won't go out of memory before the JVM has the mood to finialize and collect all those evil IClipboardDataPasteEventImpl objects.

In an ideal world of garbage collected environment, this would be unnecessary, but I guess we should all realize that our world is not perfect, and we just have to live with the flaws.

Below is my translation of the original blog entry (in Chinese) as mentioned in the question. Hopefully this can give everybody a better understanding about the issue.

Galaxy S2 memory leak with TextView

不知道是不是哪邊弄錯

Not sure where it went wrong

但是galaxy s2的textview會產生memory leak

But the textview of galaxy s2 causes memory leaks

leak是發生在android.widget.TextView$IClipboardDataPasteEventImpl這個interface上

Leak happens on the interface android.widget.TextView$IClipboardDataPasteEventImpl

它會抓住mContext造成整個activity沒辦法被gc

It holds the mContext, stopping the activity from being gc'ed

同樣的程式在htc sensation(2.3.4)跟se xperia arc(2.3.4)和acer liquid(2.1)都沒有問題

No such problem with the same app on htc sensation(2.3.4), se xperia arc(2.3.4) and acer liquid(2.1)

而且網路上完全找不到android.widget.TextView$IClipboardDataPasteEventImpl相關的資料

And, I can't find anything related to android.widget.TextView$IClipboardDataPasteEventImpl on the web at all

android source code裡也找不到看起來應該是samsung自己加的東西...

Not even in the android source code, so it seems to be something added by samsung themselves...

之前的opengl viewport bug 已經夠頭痛了接下來soundpool相關bug也搞累很多人

The opengl viewport bug was a headache already, and the soundpool related bug had frustrated many

現在這個memory leak又來攪局...

And now, here comes a memory leak messing around...

看來手機外型還是比較重要 /_\... 外型好先吸到人來買 bug再慢慢修就好

Seems that the appearance of mobile phones are more important /_\... good appearance attracts customers; bugs could be fixed later

[後記]

[P.S.]

經過一些試驗發現只要按HOME button回到桌面，那些leak就會被釋放掉...

After some tests, I found out that the leaks will be freed by pressing the HOME button to go back to the desktop...

logcat會顯示一行Hide Clipboard dialog at Starting input: finished by someone else... !

It shows Hide Clipboard dialog at Starting input: finished by someone else... ! in logcat

看起來galaxy s2裡面有偷偷對clipboard作一些操作...

It seems that galaxy s2 is operating on the clipboard under the hood...

但如果一直保持在app裡面運作的話，那些leak還是會存在...最後應該會發生OOM exception

But if we stay in the app, those leaks remain... eventually an OOM exception would occur

現在只能期望galaxy s2 的ics版會修掉這個怪問題了...

Now we can only hope that this strange problem would be resolved in the ics version of galaxy s2...