1036905 - [Peak][v1.4] graphic corruption while simply using the apps normally

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Julien Wajsberg [:julienw]]

Attachment: 2014-07-10-14-14-19.png

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.

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: graphic corruption

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.

Comment 2

[Julien Wajsberg [:julienw]]

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.

Comment 3

[Julien Wajsberg [:julienw]]

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

Comment 4

[Julien Wajsberg [:julienw]]

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.

Comment 5

[Julien Wajsberg [:julienw]]

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.

Comment 6

[Sotaro Ikeda [:sotaro]]

julienw, can you upload the logcat log?

Comment 7

[Julien Wajsberg [:julienw]]

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.

Comment 8

[Julien Wajsberg [:julienw]]

Attachment: 1036905.logcat.log

Comment 9

[Julien Wajsberg [:julienw]]

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

Comment 10

[Sotaro Ikeda [:sotaro]]

(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

Comment 11

[Sotaro Ikeda [:sotaro]]

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.

Comment 12

[Julien Wajsberg [:julienw]]

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?

Comment 13

[Sotaro Ikeda [:sotaro]]

(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.

Comment 14

[Julien Wajsberg [:julienw]]

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?

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Just set layers.enable-tiles to false.

Comment 17

[Ivan Tsay (:ITsay)]

Peak specific issue, not block 1.4 release.

Comment 18

[Julien Wajsberg [:julienw]]

Why do you NI me ?

Comment 19

[Geeksphone]

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

We tried it and improves nothing.

Comment 20

[Julien Wajsberg [:julienw]]

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

Comment 21

[Kami]

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

Comment 22

[Geeksphone]

(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.

Comment 23

[Julien Wajsberg [:julienw]]

(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).

Comment 24

[Sotaro Ikeda [:sotaro]]

(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.

Comment 25

[Sotaro Ikeda [:sotaro]]

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

Comment 27

[Panos Astithas (he/him) [:past] (please ni?)]

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