STR: * use the contacts app with enough contacts (try to enter a card, edit it, etc) * quite quickly (for me, it happens right when I enter a card), the display is corrupted This happens also in other apps (at least bookmarked websites and the SMS app), but it's very visible in the Contacts app. The funniest is that all displayed parts are interactable. I'll upload a video soon to show this. I use builds from geeksphone, but this didn't happen with builds from around mid-june. This started happening with a build from start of july (sorry, I don't have commit hashes). Could be related to bug 1029986.

At first everything looks fine, but at one point there is a graphic corruption occuring. And we can see we can interact with both parts.

30sec: first graphic corruption: some parts are white. 45sec: second graphic corruption: we can see that the letter (on the right) from the first panel are displayed, and a tile on the bottom right is displaying the first panel too.

I'm flashing a flame with v1.4 to see if this reproduces there too.

Doesn't reproduce on Flame, at least for me. But on Peak it's happening a lot, so I'm wondering if there is a way to mitigate the issue.

Note that the video and screenshot are the most visible parts; we also see that some random elements are not displayed at all (eg: the subheader in a SMS thread), some others are displayed in a wrong location (happens in the SMS app when we press "back" from a thread to the thread list), etc.

julienw, can you upload the logcat log?

Disabling the tiling make it work properly (but scrolling is less smooth obviously). (In reply to Sotaro Ikeda [:sotaro] from comment #6) > julienw, can you upload the logcat log? Yeah, I should have done that before, sorry. Capturing now.

I couldn't reproduce on a Flame capped to 273MB either.

(In reply to Julien Wajsberg [:julienw] from comment #8) > Created attachment 8453788 [details] > 1036905.logcat.log In the logcat, there are the following log. From it, it seems same to Bug 1036410. ---------------------------------------- 07-10 16:35:04.499 E/memalloc( 763): /dev/pmem: Failed to map buffer size:44134400 offset:42045440 fd:279 Error: Out of memory 07-10 16:35:04.499 E/msm7627a.gralloc( 763): Could not mmap handle 0x439ed830, fd=279 (Out of memory) 07-10 16:35:04.499 E/msm7627a.gralloc( 763): gralloc_register_buffer: gralloc_map failed 07-10 16:35:04.499 W/GraphicBufferMapper( 763): registerBuffer(0x439ed830) failed -12 (Out of memory) 07-10 16:35:04.569 E/memalloc( 763): /dev/pmem: Failed to map buffer size:46014464 offset:44134400 fd:281 Error: Out of memory 07-10 16:35:04.569 E/msm7627a.gralloc( 763): Could not mmap handle 0x439ed6f0, fd=281 (Out of memory) 07-10 16:35:04.569 E/msm7627a.gralloc( 763): gralloc_register_buffer: gralloc_map failed 07-10 16:35:04.569 W/GraphicBufferMapper( 763): registerBuffer(0x439ed6f0) failed -12 (Out of memory) 07-10 16:35:04.569 E/memalloc( 763): /dev/pmem: Failed to map buffer size:47894528 offset:46014464 fd:324 Error: Out of memory 07-10 16:35:04.569 E/msm7627a.gralloc( 763): Could not mmap handle 0x439eddd0, fd=324 (Out of memory) 07-10 16:35:04.569 E/msm7627a.gralloc( 763): gralloc_register_buffer: gralloc_map failed

I am wondering that it might be caused by gralloc limitation because of peak's gonk problem. The peak uses very old qcom unsupported platform(ics_chocolate). Around media, peak has some unfixed problems. See Bug 976433 Comment 17. graphic might also have some limitations.

I'm quite sure this is due to the gonk problem on the peak, it's not the first time it happens. Should we advise the geeksphone team to turn off tiling on their builds, or will we find a way to support it?

(In reply to Julien Wajsberg [:julienw] from comment #12) > I'm quite sure this is due to the gonk problem on the peak, it's not the > first time it happens. > > Should we advise the geeksphone team to turn off tiling on their builds, or > will we find a way to support it? It seems better to turn off tiling on their builds. It seems to be caused by their gonk, it seems not clear that we could have a workaround for it.

Dear geeksphone team, is it possible to do such a change in your builds? Sotaro, can you please point to the correct pref to disable?

Just set layers.enable-tiles to false.

Peak specific issue, not block 1.4 release.

Why do you NI me ?

(In reply to Milan Sreckovic [:milan] from comment #15) > Just set layers.enable-tiles to false. We tried it and improves nothing.

Geeksphone> I haven't tried to set the pref but I definitely saw improvements when changing the setting manually.

I am from #1029986 and changing the setting manually really improved the bad behavior. I sent these reports (not sure all of the related to this bug): bp-1181a212-aaa7-471e-b77e-4e3d92140716.txt bp-6c357ba0-df5e-4325-9a19-f5d9f2140618.txt bp-77f8d014-93fb-4fda-9cf8-eecfc2140624.txt bp-9fd24836-73cd-492a-8acf-2bc302140618.txt bp-a4b1dd14-50d2-4f00-89a3-99d022140716.txt bp-c76a078d-f33a-4e85-bc51-f9f342140625.txt bp-d160ab76-c912-41df-9a4b-fd05d2140716.txt

(In reply to Julien Wajsberg [:julienw] from comment #20) > Geeksphone> I haven't tried to set the pref but I definitely saw > improvements when changing the setting manually. When i said that improves nothing is because not solve the real issue. Out of memory on graphics and not use of ashmem when it happens.

(In reply to Geeksphone from comment #22) > (In reply to Julien Wajsberg [:julienw] from comment #20) > > Geeksphone> I haven't tried to set the pref but I definitely saw > > improvements when changing the setting manually. > > When i said that improves nothing is because not solve the real issue. > > Out of memory on graphics and not use of ashmem when it happens. Sotaro, is there anything we can do to use ashmem in that case? (I don't really understand all of this :) but I'd like things to be better on Peak as we have a bunch of power users using this device, especially app developers).

(In reply to Julien Wajsberg [:julienw] from comment #23) > (In reply to Geeksphone from comment #22) > > (In reply to Julien Wajsberg [:julienw] from comment #20) > > > Geeksphone> I haven't tried to set the pref but I definitely saw > > > improvements when changing the setting manually. > > > > When i said that improves nothing is because not solve the real issue. > > > > Out of memory on graphics and not use of ashmem when it happens. > > Sotaro, is there anything we can do to use ashmem in that case? > > (I don't really understand all of this :) but I'd like things to be better > on Peak as we have a bunch of power users using this device, especially app > developers). This problem is not normal out of pmem. If the pmen becomes out of memory, it normally happens during it's allocation in b2g process. But the error happens in client process during the buffer mapping. If out of pmem happens during gralloc allocation in b2g process, it is fallbacked to ashem correctly at gralloc hal. But the error does not happen during gralloc buffer allocation. Therefore, it can not be fallback to ashem, because gonk does not work as expected.

Bug 1039883 reduces gralloc buffer usage, it might mitigate the problem.

FWIW setting layers.enable-tiles to false fixes the issue for me on 2.1.