Closed Bug 477956 Opened 12 years ago Closed 12 years ago
Pages do not load, not even the welcome screen - checkerboard is all that is displayed
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.
From IRC, Phil said his device had 115MB program memory free, before launching Fennec.
OS: Other → Windows Mobile 6 Professional
Hardware: Other → ARM
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
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.
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.
Assignee: nobody → doug.turner
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.
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
oh, yeah. i also do not align the allocations so we are going to be pretty wasteful, but this was just a quick hack.
this really is just a dup of 478044. jemalloc solves this problem.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 478044
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.