[regression] first launch of some apps freezes the system

[diver]

hrev55862 x86_64 running in VMware.

First launch of some prefs (affected prefs: Appearance, E-mail, Keymap, Locale, Time, Sounds) as well as apps (Terminal, FirstBootPrompt and others) freezes the system for 3-5 seconds pegging CPU core.

No such problem in beta3 x86_64.

[diver]

Seems to be not related to gcc11, hrev55706 (first gcc11 nightly) is fine.

[diver]

hrev55754 is ok.

[diver]

hrev55801 is affected.

[diver]

hrev55774 is affected.

[diver]

hrev55780 is affected.

[waddlesplash]

So, this isn't any particular regression, then, but instead happens on some builds and not others? That's unfortunate...

[diver]

hrev55760 is ok.

[diver]

hrev55767 is ok
hrev55801 is affected

[diver]

hrev55767 is ok
hrev55872 is affected

[diver]

hrev55767 is ok
hrev55868 is affected

[korli]

​https://git.haiku-os.org/haiku/log/?qt=range&q=hrev55767..hrev55774 is the range to inspect, right?

[waddlesplash]

Ah, I misread things earlier. Indeed that seems to be the range to check.

hrev55768 seems the most likely culprit out of that range. I guess the BBitmap changes could somehow also be a problem inadvertently, but they should have been harmless...

[waddlesplash]

Rather by accident while investigating another issue, I noticed that _ScanFonts seems to be called the first time Terminal (and I presume those other applications) is started:

15 ffffffff81aa8f30 (+140737147826944) 0000003ed77554bc   <libroot.so> _kern_map_file + 0x0c
16 00007fff6d5e8230 (+ 192) 0000022d3b3f36ee   <libfreetype.so.6> FT_Get_WinFNT_Header (nearest) + 0x20e
17 00007fff6d5e82f0 (+  64) 0000022d3b355d07   <libfreetype.so.6> FT_Library_SetLcdGeometry (nearest) + 0x247
18 00007fff6d5e8330 (+ 448) 0000022d3b35f438   <libfreetype.so.6> FT_Done_Face (nearest) + 0x158
19 00007fff6d5e84f0 (+  80) 0000022d3b35feff   <libfreetype.so.6> FT_New_Face + 0x2f
20 00007fff6d5e8540 (+ 176) 00000042628e1377   <_APP_> FontManager::_AddFont(FontManager::font_directory&, BEntry&) + 0x
77
21 00007fff6d5e85f0 (+ 256) 00000042628e1f4e   <_APP_> FontManager::_ScanFontDirectory(FontManager::font_directory&) + 0
xde
22 00007fff6d5e86f0 (+  48) 00000042628e1fdc   <_APP_> FontManager::_ScanFonts() + 0x5c
23 00007fff6d5e8720 (+  64) 00000042628e2044   <_APP_> FontManager::CheckRevision(unsigned int) + 0x24
24 00007fff6d5e8760 (+2832) 00000042628a7caf   <_APP_> ServerApp::_DispatchMessage(int, BPrivate::LinkReceiver&) + 0x354
f
25 00007fff6d5e9270 (+ 208) 00000042628aa9f5   <_APP_> ServerApp::_MessageLooper() + 0x115
26 00007fff6d5e9340 (+  16) 000000426289dcea   <_APP_> MessageLooper::_message_thread(void*) + 0x0a
27 00007fff6d5e9350 (+  32) 0000003ed77543a9   <libroot.so> _thread_do_exit_work (nearest) + 0x89
28 00007fff6d5e9370 (+   0) 00007f76199f6260   <commpage> commpage_thread_exit + 0x00
kdebug>

I don't believe it was called before I launched Terminal, so likely this is related.

[waddlesplash]

I guess the change in hrev55768 made it so that the first ScanFonts now occurs the first time the font list is requested, as opposed to much earlier.

[waddlesplash]

This should be fixed in hrev55867; please test.

[diver]

Confirmed. Thanks!

[madmax]

It's something you can't unsee once someone tells you about it. No need for VMWare, quite noticeable in real hardware with a spinning hard disk.

I guess the change in hrev55768 made it so that the first ScanFonts now occurs the first time the font list is requested, as opposed to much earlier.

Yup. Before hrev55768, SetFace would always CountStyles and that'd scan the fonts, with the freeze happening before showing the desktop icons and the Deskbar. After your fix it happens before even having the desktop background. I guess I should look into ways to remove the need to lock the font manager for the whole duration of the scan.

[waddlesplash]

I guess I should look into ways to remove the need to lock the font manager for the whole duration of the scan.

Yes, I had the same thought, but I wasn't sure about how the global FreeType object was used/protected, so I decided to leave that attempt for someone else.

[waddlesplash]

Since we are now using Fontconfig in app_server for other things, perhaps we should use it here (and make use of its caches) instead of scanning all fonts like this?

[diver]

Replying to madmax:

Yup. Before hrev55768, SetFace would always CountStyles and that'd scan the fonts, with the freeze happening before showing the desktop icons and the Deskbar. After your fix it happens before even having the desktop background. I guess I should look into ways to remove the need to lock the font manager for the whole duration of the scan.

Has this been fixed ot should I open a ticket for that?

[madmax]

If you mean having the manager locked while the font directories are scanned, there have not been changes.