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

Status: RESOLVED INCOMPLETE

(Core :: Layout: Text and Fonts, defect)

Description

[timeless]

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

[Marc Attinasi]

recent regression or old bug?

Comment 2

[timeless]

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

[Marc Attinasi]

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

[rbs]

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. 

Comment 5

[timeless]

i'm going to test 081 as soon as i finish this morning's bugmail

Comment 6

[timeless]

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.

Comment 7

[timeless]

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

[Shanjian Li]

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. 

Comment 9

[timeless]

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.

Comment 10

[rbs]

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

Comment 11

[rbs]

The bug now seems fixed by combination of bug and bug 136248

Comment 12

[rbs]

...following bug 135535 and bug 136248, this bug needs to be re-evaluated. It may
already be fixed.

Comment 13

[Christopher Hoess (gone)]

->Fonts & Text. If someone with the necessary expertise could examine this...

Comment 14

[Jungshik Shin]

timeless, do you still have a Win98? Is this still a problem?

Comment 15

[timeless]

sorry, no. tardis died and raistlin is waiting for me to find a home for it.

Comment 16

[Andrei Purice]

Hey timeless,
Can you still reproduce this issue or should we close it?

Comment 17

[Andrei Purice]

Marking this as Resolved > Incomplete since the last activity on this issue was 18 years ago and it might not be relevant anymore.
Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.