301404 - Beachballing a lot (ResetFontNamesCache, fixed in 10.4.3?)

Status: RESOLVED WORKSFORME

(Camino Graveyard :: General, defect)

Description

[Avi Drissman]

Gawd, that's an awful summary. Using 2005071808 (0.9a2) on 10.4.2.

Things lock up a lot now. I have a sampling (the auto kind from Spin Control)
from a 10-second lockup on slashdot, and a 2.5 second one from bugzilla. They
look different; I'm not sure about splitting the bugs.

Comment 1

[Avi Drissman]

Attachment: 10-sec lockup at slashdot

This one seems to be reflowing like mad while loading

Comment 2

[Avi Drissman]

Attachment: 2.5 sec lockup on bugzilla's query page

while this one seems to be madly repainting.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

In the bugzilla situation, was the caret flashing madly in the summary field? 
I've been seeing that occasionally over the past couple of weeks, but it's
happening almost constantly this browser session (same build, 10.3.9).

Comment 4

[Avi Drissman]

Not applicable. This is while the page is loading from the network or drawing on
the screen.

What's nasty is that not only is it pegging the CPU, but it's all system time,
not user time.

I seem to see something similar with Thunderbird. This might be a core problem...

Comment 5

[Simon Fraser [no longer active]]

Both saamples shows a lot of time in reflow, much of which is spent down in
QuickDraw, under TextWidth(), doing some kind of font database sync:

  348 TextWidth
    347 CallTextWidth
      347 StdTxMeas
        347 LockGrafPortFontResult
          347 LockFontResult
            347 FMSwapFont
              344 FOGetGeneration
                344 _eFOGetGeneration
                  344 AssureDBGenerationSynched
                    341 SendSynchronizeDatabaseMessage()
                      225 SynchronizeDatabaseInformation(DBSynchMessageReply*)
                        123 ResetFontNamesCache

I've seen this on one of my machines, and believe it to be an issue in 10.4. The
dev 10.4.3 change notes list:
  ResetFontNamesCache() performance enhanced
as one of the changes.

Comment 6

[Simon Fraser [no longer active]]

(In reply to comment #5)
> The dev 10.4.3 change notes list:
>   ResetFontNamesCache() performance enhanced
> as one of the changes.

Note that I found this via google on:
http://www.neowin.net/forum/lofiversion/index.php/t350675.html

Comment 7

[Mike Pinkerton (not reading bugmail)]

i saw this today on apple's developer pages. spending about a minute with
threadViewer showed the exact same behavior as the sample (10.4.2, 2005083004
branch)

i swear it wasn't always this bad. are we sure nothing changed on our end
besides the OS?

Comment 8

[Simon Fraser [no longer active]]

I just saw this problem on
http://www.randi.org/jr/200509/091605church.html#1

The problem was also accompanied by a weird mouse offset issue, where selecting
text both in the native Cocoa UI, and in the content area would behave as if the
mouse was offset both horizontally and vertically from its actual position.

I'd had Java runner earlier, and then turned it off (although some JVM threads
were still running, according to ThreadViewer).

When I quit and restarted Camino and went back to the page, everything was fine.
I wonder if Java or the JEP is causing a problem here?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

> I wonder if Java or the JEP is causing a problem here?

Off the top of my head I'd say this is very unlikely.  But when I have more
time I'll look into it.

Comment 10

[Simon Fraser [no longer active]]

FWIW I just saw BBEdit stuffering from this same issue. I'm pretty sure it's an
OS bug.

Comment 11

[Samuel Sidler (old account; do not CC)]

*** Bug 301513 has been marked as a duplicate of this bug. ***

Comment 12

[Simon Fraser [no longer active]]

10.4.3 is out; please keep an eye open for this one.

Comment 13

[Simon Fraser [no longer active]]

I'm pretty sure 10.4.3 fixed this (backed up by reports on Macintouch).