We hold onto way too many font resources while rendering intl pages

NEW
Unassigned

Status

()

defect
--
major
18 years ago
10 years ago

People

(Reporter: timeless, Unassigned)

Tracking

Trunk
mozilla1.2alpha
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [FIXED?], URL)

(Reporter)

Description

18 years ago
2001101603

w98se [probably won't happen in NT]
smoketest IB.3FAILS. because we're holding font resources!!

we hold fonts so terribly, mozilla can no longer render those pages!!  notepad
eventually has bad fonts, the start menu stops showing children (and uses 8
instead of |>), alt-printscreen displayed an error message -- pretty impressive

steps:
from smoketest page, load http://www.unicode.org/iuc/iuc10/x-ncr.html in a new tab.
go back to smoketest http://home.jp.netscape.com/ja/index1.html in a new tab
go back to smoketest tab, copy http://home.netscape.com/ko/ go back to ja page
load ko, go back to smoketest tab copy http://home.netscape.com/zh/cn/ go back
to ko load cn, back to smoke copy http://home.netscape.com/de/index1.html back
to cn load de.
go back twice. result: fonts don't render. a bit more switching and i noticed
notepad and everything else including new mozilla windows used standard system
fallback fonts. closing the tabbed window released the fonts and fixed notepad.

This might be an interaction with tabs but i think the pages in history should 
just release whatever font stuff they're holding.

Offhand, i don't know of a tool for 9x that would show me what resources an app
is allocating, i can dig for one if necessary.  Interestingly enough mozilla
didn't crash unlike previous times when i ran out of resources on this box.
however, not closing that window does make the os pretty close to unusable.

Comment 1

18 years ago
recent regression or old bug?
(Reporter)

Comment 2

18 years ago
dunno, i only started using w98 a few weeks ago, and had never really tried
smoketesting w/ it. If it's new then rbs is probably to blame. fwiw, i found a
tool that logs api calls for stuff like this, but using it only made it easier
for me to crash my entire system.

Comment 3

18 years ago
If someone on Win98 (or 95) could check this on an older build we might be able
to quickly tell if this is a regerssion from rbs changes. Timeless, petersen,
can you help?

Comment 4

18 years ago
timeless, watch out for your buggy OS as in the case of bug 102949 :-)

More seriously... as Marc said, please grab an older build and test things out.
By design, font resources are cached (not something new from my changes) -- and 
there could be lot of things around if you are trying to display huge portions 
of the Unicode table at once, and keeping them live in tabs... It is anticipated 
that the GDI would do its part of the caching. Since its inception, the font 
subsystem has seen huge efforts into correctnesss and robustness  -- Mozilla 
would be built on shaky grounds otherwise. Recently though, efforts have 
initiated at compacting the resources (see bug 102706 for what is coming next in 
GfxWin, similar effort went in GfxGtk in bug 95518). Sharing is another 
long-term goal.

Another build that you could try is the special build that could log what is 
happening and tell if things are just leaking out or not (see the comments in 
bug 103473 & bug 102900). Although the logs so far show that leaks have been 
nailed quite well. 
(Reporter)

Comment 5

18 years ago
i'm going to test 081 as soon as i finish this morning's bugmail
(Reporter)

Comment 6

18 years ago
Yes it happens in 0.8.1 too.

For comparison. IE6 is not this evil.  I have the same pages loaded w/ it now
(after i quit m0.8.1) and nothing is experiencing the resource lossage.  I can
try n3 but i suspect its age might make it uninteresting.
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 7

18 years ago
for reference n3 of course doesn't have this behavior.

after crashing a lot i do think that tabs help me crash faster, however it's 
possible that tabs just let me have more content open w/o realizing how many 
windows i would have had if i needed to use windows.

if i remember, i'll try the logged builds.

Comment 8

18 years ago
My patch for bug 109974 might solve part of the problem. We might need to set a 
limit for font cache in win95/98 if it does not. It is well known that on 
win95/98, gdi object is shared globally and has very limited number (256?). 
If all font resources will be release as soon as mozilla finished rendering a 
certain page, it is OK to hold font resources temporarily. At least through my 
past debugging experience, that seems the case. 
(Reporter)

Comment 9

18 years ago
you're my hero. if the problem goes away when that's fixed i'll mark this as a 
dupe, otherwise we can research the limitation stuff.
Depends on: 109974

Updated

18 years ago
No longer depends on: 109974
Target Milestone: mozilla1.0 → mozilla1.2

Comment 10

18 years ago
timeless, are you okay now that bug 109974 has been fixed?

Comment 11

17 years ago
The bug now seems fixed by combination of bug and bug 136248

Comment 12

17 years ago
...following bug 135535 and bug 136248, this bug needs to be re-evaluated. It may
already be fixed.
->Fonts & Text. If someone with the necessary expertise could examine this...
Assignee: attinasi → font
Component: Layout → Layout: Fonts and Text
QA Contact: petersen → ian
Whiteboard: [FIXED?]

Comment 14

15 years ago
timeless, do you still have a Win98? Is this still a problem?
(Reporter)

Comment 15

15 years ago
sorry, no. tardis died and raistlin is waiting for me to find a home for it.
Assignee: layout.fonts-and-text → nobody
QA Contact: ian → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.