[DEV/DEBUG] CM11 debug thread for Falcon

[VictoriousShooter]

Seems like it is some kind of device related difference. I am using the German o2 version and have the RAM bug. I think it is the xt1032.


Sent from my Moto G using XDA Premium 4 mobile app

I'm also using the XT1032

Oh good god, now it's device specific? Why can't these bugs just be universal and easy or fix?

Sent from my XT1031 using Tapatalk

 

[SWTR]

What is this "Timed Event Queue" for a wakelock?

 

[matmutant]

I'm also using the XT1032

Me too, XT1032, French retail, 8GB, i would say "second batch" (i had it with the black case with silver logo)

 

[ig0r260892]

ram bug here on XT1032 too

Sent from my Moto G using XDA Premium 4 mobile app

 

[Carlos_EVH]

I have a xt1032 and i suffered the bug too

 

[matmutant]

uptime : 1 day, 16hrs + ...
and still 170 000kB lost (this is really stable since a while)

i believe the bug exist, but as you see, seems i can't replicate it for today :cyclops:

 

[ph4zrd]

Im currently trying to reproduce the ram bug on a build I compiled 30min ago. So far I couldn't achieve more than 100 MB of "Lost RAM", currently it's at ~45 MB.

Because someone said the bug happens with all versions since 20140224, I searched for commits in the device specific repositories that were pushed just after this date, especially in the kernel and qcom display repository. What I found were some commits from 26/02 in android_kernel_motorola_msm8226: https://github.com/CyanogenMod/android_kernel_motorola_msm8226/commits/cm-11.0?page=11
I tried to revert those (cc12abf69bf608b1accffb15682bdeecd36aaaa3..6a8acccc9a65df6cd8782d8858003dea75cfa6e8), got an error during compilation and reverted 518351814c0f60c3ffad26bead05624b668c05ee in android_hardware_qcom_display-caf-new as well (git blame helped here).

It seems that there are still some problems, "Lost RAM" does not go below 40 MB and rises sometimes to as high as 95 MB. But maybe that's just normal. I will test the build for some hours/days and report. If I don't get any problems, I may upload it for others to try so we can verify that the bug was introduced by said commits and track it down further.

 

[Gronnd]

Some progress at last, thank goodness, and thanks ph4zrd, let's wait your report

 

[Hubik82]

I have XT1032 and RAM bug is annoying. Today after installing latest build and running system for about 6 hours, phone was almost unusable. Launching any "big" app like FB or Viber or any game (even simple like Candy Crush) was causing FC, thrn launcher and wallpaper redrawing etc.

After reboot phone is smooth again but after next couple of hours problems are back...

Sent from my Moto G running CM11

 

[matmutant]

FYI,

CM11 on N5 with an uptime of 5hrs : 185373kB
Paranoid Android +Franco Kernel on Gnex with an uptime of 4hrs : -39999kB (yeap a minus result ...) [note this device isn't a daily used phone]

waiting for results after 1 day

i just want to see if there is similar things on other devices

 

[ph4zrd]

No major problems so far. RAM usage seems to increase over time like in official CM, but much slower and less predictable. "Lost RAM" drops by 20-30 MB from time to time. It feels like my voodoo "fixed" one of some more problems, but only longer testing will tell.

So here you go. Standard disclaimer, no warranty yadda yadda yadda.

[...]

Total PSS by category:
   108786 kB: Native
   101428 kB: Dalvik
    52426 kB: .dex mmap
    48599 kB: .so mmap
    47478 kB: Dalvik Other
    20583 kB: Other dev
    15317 kB: Ashmem
    13803 kB: .apk mmap
     6924 kB: Unknown
     4286 kB: Stack
     3092 kB: Other mmap
     1734 kB: .ttf mmap
      170 kB: .jar mmap
        8 kB: Cursor
        0 kB: code mmap
        0 kB: image mmap
        0 kB: Graphics
        0 kB: GL
        0 kB: Memtrack

Total RAM: 903272 kB
 Free RAM: 469660 kB (110976 cached pss + 274788 cached + 83896 free)
 Used RAM: 373874 kB (313658 used pss + 3608 buffers + 11320 shmem + 45288 slab)
 Lost RAM: 59738 kB
     ZRAM: 4304 kB physical used for 15248 kB in swap (131068 kB total swap)
      KSM: 44048 kB saved from shared 8208 kB
           184956 kB unshared; 326004 kB volatile
   Tuning: 64 (large 256), oom 122880 kB, restore limit 40960 kB (high-end-gfx)

up time: 03:39:53, idle time: 01:56:57, sleep time: 01:35:43

$ md5sum cm-11-20140319-UNOFFICIAL-falcon-test2.zip 
690636b7b10bd48bcec4fc9a8116fed6  cm-11-20140319-UNOFFICIAL-falcon-test2.zip

Edit: Test build removed, use cm nightly + zip from here.

 

[Jocker111]

https://www.dropbox.com/s/8t3igu1cyslu8oz/cm-11-20140319-UNOFFICIAL-falcon-test2.zip

Wooohooo, that works for me too... Let's see the long-term usage, but I'm not able to increase memory by just pressing the power button.

Thank you very much!

 

[mcpaddington]

Googled around to see if I could find any other device that has a similar issue to the lockscreen ram bug and found that the old galaxy nexus had a problem that closely resembles ours(albeit our issue seems to be more taxing on ram). Here's the thread, the last post mentions that the guy submitted a patch to AOKP to fix the issue which was accepted. Maybe someone with a bit more experience can tackle this.

Thread: http://forum.xda-developers.com/galaxy-nexus/help/excessive-ram-usage-t1584606

AOKP gerrit patch: http://gerrit.aokp.co/#/c/878/

 

[robin0800]

Googled around to see if I could find any other device that has a similar issue to the lockscreen ram bug and found that the old galaxy nexus had a problem that closely resembles ours(albeit our issue seems to be more taxing on ram). Here's the thread, the last post mentions that the guy submitted a patch to AOKP to fix the issue which was accepted. Maybe someone with a bit more experience can tackle this.

Thread: http://forum.xda-developers.com/galaxy-nexus/help/excessive-ram-usage-t1584606

AOKP gerrit patch: http://gerrit.aokp.co/#/c/878/

There is a suggested patch on post # 49 of this thread

 

[NZ_Kobra]

ph4zrd's build

What are people's experiences with ph4zrd's build?
Has the lost memory issue been resolved for you?

 

[SWTR]

What are people's experiences with ph4zrd's build?
Has the lost memory issue been resolved for you?

Till now, yes

 

[pinguijxy]

What are people's experiences with ph4zrd's build?
Has the lost memory issue been resolved for you?

I just want to note that he didn't resolve the problem but pin pointed a culprit commit and reverted the changes made by that commit. The next step is to look at the reverted commit and patch it so that it can be put back into the code base without causing a RAM leak.

Sent from my Moto G using XDA Premium 4 mobile app

 

[Jocker111]

What are people's experiences with ph4zrd's build?
Has the lost memory issue been resolved for you?

So far, my lost memory is at 100mb, but it does not rise anymore since quite some time.

Maybe I'm a little bit too full of expectation, but I still do not understand how it can be so hard to debug this issue. How is it possible, that this memory usage is NOT seen by procrank / ps / dumpsys meminfo / top / etc...
All these tools show the current usage of all processes running on my phone. So there is a much deeper problem, than just this issue.

Yes this issue seems resolved but from another viewpoint the much bigger problem, namely that we could not even pin point the process which caused the problem, is in my oppinion neither solved nor was it tackeled in any way.

 

[ph4zrd]

So far, my lost memory is at 100mb, but it does not rise anymore since quite some time.

Maybe I'm a little bit too full of expectation, but I still do not understand how it can be so hard to debug this issue. How is it possible, that this memory usage is NOT seen by procrank / ps / dumpsys meminfo / top / etc...
All these tools show the current usage of all processes running on my phone. So there is a much deeper problem, than just this issue.

Yes this issue seems resolved but from another viewpoint the much bigger problem, namely that we could not even pin point the process which caused the problem, is in my oppinion neither solved nor was it tackeled in any way.

The relevant commits (cc12abf69bf608b1accffb15682bdeecd36aaaa3 to 6a8acccc9a65df6cd8782d8858003dea75cfa6e8, found here) are part of the msm graphics code, so maybe it's graphics memory that gets reserved by the system and as such is not bound to a process?!
Maybe someone can explain how this graphics concept works, what mdss is and what it has to do with an iommu?

So reverting all those ~30 commits seems to "resolve" the basic issue of leaking memory. We still have to understand how they lead to the leak and by which line(s) it is caused to fix it finally.

Another helpful comment by GuzTech that I got via private message:

Hi ph4zrd,

I'm sending you a private message since I just registered on XDA and cannot comment in the "CM11 debug thread for Falcon" thread yet, because I do not yet have at least 10 posts

I also have the XT1032 and everytime I cycle through power on/sleep by repeatedly pushing the power button, my RAM usage starts to increase. Using dumpsys meminfo, I found that every single time I do this, my memory usage is increased by a little more than 1280 * 720 * 4 = 3686400 bytes. This lead me to believe that somewere there is a leaf of the size of the framebuffer + a little overhead.

The increase is always at least this amount and usually a little bit more, and it is consistent with the sleep/wake up cycle. I'm very new to Android development and right now I'm trying to look for places where such a memory leak could appear. Hopefully this information helps.

Cheers

It sounds plausible to me that the graphics code stores copies of the framebuffer somewhere and doesn't free the memory afterwards. But I still don't understand the concept of the msm graphics stack, so these are only speculations.
@dhacker29 or @Entropy512, maybe one of you can provide some clarity or help fixing this.

 

[alokhan]

Googled around to see if I could find any other device that has a similar issue to the lockscreen ram bug and found that the old galaxy nexus had a problem that closely resembles ours(albeit our issue seems to be more taxing on ram). Here's the thread, the last post mentions that the guy submitted a patch to AOKP to fix the issue which was accepted. Maybe someone with a bit more experience can tackle this.

Thread: http://forum.xda-developers.com/galaxy-nexus/help/excessive-ram-usage-t1584606

AOKP gerrit patch: http://gerrit.aokp.co/#/c/878/

this class does not exist anymore in the current tree