Last Comment Bug 477956 - Pages do not load, not even the welcome screen - checkerboard is all that is displayed
: Pages do not load, not even the welcome screen - checkerboard is all that is ...
Status: VERIFIED DUPLICATE of bug 478044
Product: Fennec Graveyard
Classification: Graveyard
Component: General (show other bugs)
: Trunk
: ARM Windows Mobile 6 Professional
-- critical with 1 vote (vote)
: ---
Assigned To: Doug Turner (:dougt)
Depends on: 478044
  Show dependency treegraph
Reported: 2009-02-10 21:26 PST by Phil
Modified: 2009-08-21 12:07 PDT (History)
18 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

patch v.1 (4.33 KB, patch)
2009-02-17 09:57 PST, Doug Turner (:dougt)
no flags Details | Diff | Splinter Review
patch v.2 (2.14 KB, patch)
2009-02-19 12:46 PST, Doug Turner (:dougt)
no flags Details | Diff | Splinter Review

Description User image Phil 2009-02-10 21:26:48 PST
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 and 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 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:  

Expected Results:  
I expected to see an iteration of or, 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 community.  Information on the settings of the custom rom can be found here:
Currently, I am using version 4.9.4 of the custom rom.
Comment 1 User image Mark Finkle (:mfinkle) (use needinfo?) 2009-02-10 21:34:38 PST
From IRC, Phil said his device had 115MB program memory free, before launching Fennec.
Comment 2 User image Doug Turner (:dougt) 2009-02-12 00:39:30 PST
i have confirmed that the problem happens immediately following an allocation failure in gfxImageSurface:

The caller is OnPaint() from the windows widget code.
Comment 3 User image Ken Sears 2009-02-14 12:48:28 PST
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 User image Doug Turner (:dougt) 2009-02-17 09:57:41 PST
Created attachment 362735 [details] [diff] [review]
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 User image Doug Turner (:dougt) 2009-02-17 18:39:15 PST
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 User image Doug Turner (:dougt) 2009-02-19 12:46:46 PST
Created attachment 363179 [details] [diff] [review]
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:
Comment 7 User image Doug Turner (:dougt) 2009-02-19 12:47:51 PST
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 User image Doug Turner (:dougt) 2009-03-13 08:11:34 PDT
this really is just a dup of 478044.  jemalloc solves this problem.

*** This bug has been marked as a duplicate of bug 478044 ***
Comment 9 User image Aakash Desai [:aakashd] 2009-08-21 12:07:18 PDT
dupe v.

Note You need to log in before you can comment on or make changes to this bug.