477956 - Pages do not load, not even the welcome screen - checkerboard is all that is displayed

Status: VERIFIED DUPLICATE of bug 478044

(Firefox for Android Graveyard :: General, defect)

Description

[Phil]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: m11 (Fennec Windows Mobile milestone release)

Downloaded the Windows Mobile Fennec Milestone release on 2/10/08.  Fennec launched, but the welcome screen was not displayed - the checkerboard loading screen was all that I saw.  I tried google.com and wikipedia.com with the same result: pages would not load.  The loading icon - the circle on the left side of the address bar - would indicate loading, and then would display the icon (for example, the Wikipedia icon) as if loading had finished successfully.  

Reproducible: Always

Steps to Reproduce:
1. Go into Programs and select Fennec
2. Fennec will open, but the welcome screen will not load.
3. Type wikipedia.com into address bar and press enter.  Loading icon will act like it is loading the page, but page will not load.  The checkerboard never leaves the screen.
Actual Results:  
Checkerboard.

Expected Results:  
I expected to see an iteration of google.com or wikipedia.com, be it the mobile version or the desktop version.

I am using the Sprint HTC Touch Pro.  I am not using a stock rom, I am using a custom rom created by the ppcgeeks.com community.  Information on the settings of the custom rom can be found here: http://forum.ppcgeeks.com/showthread.php?t=52695
Currently, I am using version 4.9.4 of the custom rom.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

From IRC, Phil said his device had 115MB program memory free, before launching Fennec.

Comment 2

[Doug Turner (:dougt)]

i have confirmed that the problem happens immediately following an allocation failure in gfxImageSurface:

http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/gfxImageSurface.cpp#80

The caller is OnPaint() from the windows widget code.

Comment 3

[Ken Sears]

The same thing is happening to me and I am using a stock ROM. I even reset my device back to factory default and the only thing I've loaded on is fennec and I still the same problem.

Comment 4

[Doug Turner (:dougt)]

Attachment: patch v.1

In this patch, i simply keep a memory buffer around for use in OnPaint (responding to WM_PAINT).

We need to tie up HeapMinimize to call SHCloseApps() so that we can try to recover memory in case of a memory failure.

What do you think we should do if we can not allocate this buffer?  MessageBox?  It isn't clear that we can put up a xul dialog.


I think it would be nice to have a gfxImageSurface constructor that doesn't need a stride, but can calculate it internally based on the h/w and format.

I keep the raw buffer, instead of the actual gfxImageSurface, because occasionally I see that the underlying cairo surface that the gfxImageSurface owns has a bad status.  It might be nicer to be able to "reset" or reinitalize the gfxImageSurface such that I can simply hold the gfxImageSurface.

Comment 5

[Doug Turner (:dougt)]

The above patch is a band-aide, partial at best.  we allocate alot of buffers during drawing.  The theory is that because we have a very small amount of memory to begin with and this memory get somewhat fragmented during runtime, allocations may fail because the allocator can not find a contiguous area to alloc.

In gfxImageSurface, during panning, we allocate many small buffers (from a few bytes to a few k).  If any of these fail, we will draw incorrectly or stop drawing.  

This patch tries to stop potential fragmenting by caching the largest buffer we have seen.

There might be other places that we can do similar things.

However, I am not sure that we should just start caching stuff as our total memory usage over time is just going to get huge.  We really should fix this more generally if possible.  jemalloc is currently our best bet.

Comment 6

[Doug Turner (:dougt)]

Attachment: patch v.2

this uses a different approach.  in the gfxImageSurface we use VirtualAlloc to force allocations into the "Large Memory Area" (LMA) between 42000000 and 7E000000.  The way I am doing it is a terrible hack because we arent really keeping track of anything -- we just reserve at least 2mb (to get a reserve outside our slot address space), then allocate from that reserve what we actually need.

For deallocation, i tried using both release and/or decommit. Did not seem to matter.

With this patch we are not getting the checkerboard, but we do run out of memory / crash after a few page loads.  This illustrates that we can successfully allocate into the LMA, and use the memory successfully.

The real solution here is to use a different allocator so that we can allocate from both our slot and the LMA.

I posted a build here:  http://people.mozilla.org/~dougt/fennec-virtual-alloc-hack-0.11.en-US.wince-arm.cab

Comment 7

[Doug Turner (:dougt)]

oh, yeah.  i also do not align the allocations so we are going to be pretty wasteful, but this was just a quick hack.

Comment 8

[Doug Turner (:dougt)]

this really is just a dup of 478044.  jemalloc solves this problem.

Comment 9

[Aakash Desai [:aakashd]]

dupe v.