Opened 4 weeks ago

Last modified 4 weeks ago

#18868 new bug

Desktop becomes unusable after updating noto package

Reported by: davidkaroly Owned by: axeld
Priority: critical Milestone: Unscheduled
Component: Servers/app_server Version: R1/Development
Keywords: Cc: madmax
Blocked By: Blocking:
Platform: All

Description

Steps to reproduce:

  1. Install Haiku from latest nightly e.g. hrev57669
  2. Reboot into the freshly installed Haiku system
  3. Update noto package either with SoftwareUpdate or from the command line

Expected behavior:

  1. Noto package is updated
  2. I can continue using my system

Actual behavior: user interface falls apart, it's not possible to select any menu or icon any more. (see screenshot)

Alternatively, can we build the nightly images with latest noto package if this one is particularly problematic during an update?

Attachments (1)

Desktop_fell_apart.png (25.7 KB ) - added by davidkaroly 4 weeks ago.
screenshot

Download all attachments as: .zip

Change History (4)

by davidkaroly, 4 weeks ago

Attachment: Desktop_fell_apart.png added

screenshot

comment:1 by waddlesplash, 4 weeks ago

Cc: madmax added
Component: User InterfaceServers/app_server
Owner: changed from stippi to axeld

My initial guess would have been that, since the font files got deleted, their mmap areas were trashed. But maybe this isn't the case since it looks like fonts are still rendering, but the metrics are all wrong?

Presumably this is an app_server bug. madmax may have some ideas.

in reply to:  1 comment:2 by madmax, 4 weeks ago

Replying to waddlesplash:

[...] guess that, since the font files got deleted, their mmap areas were trashed.

That shouldn't happen, like deleting a file doesn't really remove it until all references are closed? I did a quick mmap test and to my limited knowledge I could access the data until the call to munmap, even if the file came from a package and I uninstalled or updated it while reading.

There are probably quite a few issues here.

For starters, as far as I know, a BFont doesn't pin a server font (I *think* setting it as a view's font does). So using BFont's TruncateString, StringWidth and company will pass the app server a font id that may not exist anymore, an error is returned, the arrays are not touched and havoc ensues.

In fact, you don't even need to delete a font to see some client effects: open a bunch of windows for an expanded deskbar view and change the menu font size in appearance. The font doesn't change, as the BMenu sets it on init (you can also see that in other already open apps vs new ones). The space each window item takes does change, though, as it is recalculated when drawn using the desktop settings and not the font really used. And the total height taken by all the items is updated somewhere else, so you'll get empty space at the bottom if you reduced font size or lose entries if you increased it, until that update is triggered.

And then there may be problems in app_server. If a style is still referenced, it will not be removed on uninstall. Then the insertion would fail on installation of the new version, as we already have it. And I guess (but will have to check it) the references may later disappear taking the style with them.

With respect to be_plain_font and friends, the client BFont is initialized on app initialization. The server does get a reference too, so I think those should continue working, unless there's some AS_SET_SYSTEM_FONT message involved.

Note: See TracTickets for help on using tickets.