Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Mon, 17 May 2021 at 18:12:35 +0200, Cyril Brulebois wrote:
> And for those not following #debian-boot, I'm finding myself between a
> rock and a hard place, as both options (trying to work around the
> rendering-related hangs versus switching to GTK 3 at the last moment)
> are very far from ideal… I'm not sure what we'll end up doing, and I'm
> happy to get some “votes” pro or against any of those options, and to
> hear about other options entirely.

My instinct is that it's far, far too late to be moving to GTK 3 this
cycle, and I'd prefer to get a suitable hack into GTK 2 if we can
find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting
the installed system.

I think d-i will need to move to GTK 3 early in the Debian 12 cycle,
but hard freeze is not the time to be fast-forwarding through 10 years
of GUI library development.

I've continued to look into GTK2/Pango with some rather extensive printf
debugging. I have other responsibilities and I'm trying to learn how
GTK/Pango text layout works from first principles (I'm in the GNOME
team but not really a GUI developer), so it's slow going, but I have
some ideas for things that might be able to break the loop. It's not
clear to me yet whether this is a GTK 2 bug, or a Pango bug, or what.
GNOME team members who actually know what they're doing are welcome
to step in any time.

Upstream are going to be incredibly reluctant to help us with GTK 2,
given that it has been deprecated in favour of GTK 3 for a decade, and
is officially EOL now that GTK 4 has stable releases. Pango does seem
like it's doing the wrong thing here, but perhaps GTK 2 or cdebconf is
holding it wrong.

Getting
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4
into cdebconf would make this easier, although we can revert it for the
sake of a smaller diff once we think we have a solution if the release
team are grumpy about it.

Philip Hands wanted to get this running under automated testing, but my
current GTK 2 and Pango patches are spamming the syslog at 3 million lines
a minute when they get into the loop, so we're going to have logistical
difficulties in saving logs.

It looks as though the problem is that the size GTK chooses for a
GtkTextView (a debconf "note" or similar) is flapping between two
values. GTK asks Pango "if you wrap lines at width x, how much space
will you need?", then uses the result to re-run the layout algorithm,
which changes the width available, which causes the layout algorithm to
be re-run and so on. Under normal circumstances, this runs for a few
iterations and then stabilizes at one size, terminating the loop, but
when I select Sinhala from the language menu, the width flaps between
71 and 72 pixels, with each re-layout resulting in the other width.

I think this might be related to the fact that when the layout is
calculated at the narrower width, Pango decides that there isn't space
to put the "." at the end of a paragraph on the same line as the last
word, and so wraps it to the next line, which is fine; except that
you'd expect the space required for the last word to get a bit smaller
when the "." is not included, but actually Pango tells GTK that it will
need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it
flapping between the narrower and wider width. I don't know why that
happens - perhaps the Indic shaper is drawing a character at the end of
a line more elaborately, or something?

However, either 71 or 72 pixels seems a ridiculous width to be trying to
squish multiple sentences into, so arguably it's a bug in GTK 2's layout
algorithm that it is even considering that as a size. The GTK 2 layout
algorithm does not necessarily make much sense, and the fact that it
can feed back into itself is probably a GTK 2 design flaw. During the
GTK 3 cycle it was redone to be in terms of "height for width" (if I
give you this width, how much height will you need? the mode cdebconf
will end up using) and "width for height" (the opposite, rarely used) -
so hopefully GTK 3 avoids this failure mode. However, it also seems wrong
that telling Pango that less width is available can result in it saying
it needs *more* minimum width, and maybe preventing this from happening
would get GTK 2 to do the right thing.

My next thing to get a try when I get a chance will be to make GTK refuse
to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
outside that limit, with a g_warning(). This might result in the text
being clipped at the right margin (or left margin in Hebrew/Arabic), or
even having its "ink rectangle" overlap with the next widget to the right
(or left); but for d-i, which always uses the full screen width and in
practice has a generous amount of space for its text, we might get away
with it? In a very brief test that seemed to resolve the Sinhala thing,
but I haven't tried the other paths that lead to infinite loops. Please
could someone who has tried the other scenarios provide a walkthrough?

If you want to replicate my super-verbose printf debugging:

* https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4
* apply https://people.debian.org/~smcv/bug987587/20210516/gtk+2.0/ to
  gtk+2.0 (the patch to d/rules applies directly, the patch to GTK
  applies via d/patches)
* apply https://people.debian.org/~smcv/bug987587/20210516/pango/ to
  pango1.0
* repeat test steps that I previously sent to this bug
* look at the syslog and despair
* you will want to truncate the syslog before repeating debugging,
  and send some strategic SIGSTOP to the debconf process when not actively
  letting it run, because otherwise the initramfs will run out of RAM

I'll send a separate reply to -boot about the possibility of moving to
GTK 3.

    smcv