RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars

[Kevin Rushforth]

On Thu, 11 Jun 2020 13:30:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 87:
>> 
>>> 86:
>>> 87:     private Map<TextRun, Long> runUtf8 = new HashMap<>();
>>> 88:     public void layout(TextRun run, PGFont font, FontStrike strike, char[] text) {
>> 
>> In order for this to work, each TextRun would need to be immutable (at least during the life of this PangoGlyphLayout)
>> and there would need to be a 1-1 mapping between the TextRun and the string pointer, independent of anything else. Is
>> this the case? I'm seeing some crashes in OSPango.g_utf8_offset_to_pointer when testing. I don't know if they are
>> related to this or not.
>
> I would assume that once the layout method is called, the TextRun won't change anymore. If it would change, the current
> code might break as well, as the string pointer is currently cached. I agree though that this is a brittle approach.
> What I'm basically doing here is store additional information (the number of unicode codepoints rather than the number
> of UTF 16 chars, which can then be mapped to the string pointer pointing to the relevant substring) on the TextRun, but
> since I didn't want to modify TextRun, that additional info is stored in this Map. I'd prefer modifying TextRun though.

I think I see what you are trying to do, but there are a couple of problems it is causing. I attached a new test
program to the JBS bug report, UnicodeTextTest2.java, which avoids any null (0) characters. That test runs fine today,
and with the first version of your fix (the one without the Map), but causes assertion failures with the current
version of the patch:

(java:32761): Pango-CRITICAL **: 10:37:09.535: pango_itemize: assertion 'length >= 0' failed

(java:32761): Pango-CRITICAL **: 10:37:09.963: pango_itemize: assertion 'length >= 0' failed

I also sometimes get this:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f00456c2d78, pid=32761, tid=32778
#
# JRE version: Java(TM) SE Runtime Environment (14.0+36) (build 14+36-1461)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14+36-1461, mixed mode, sharing, tiered, compressed oops, serial gc,
linux-amd64) # Problematic frame:
# C  [libglib-2.0.so.0+0x84d78]  g_utf8_offset_to_pointer+0x28

Phil is the expert here, so I'd like him to weigh in.

-------------

PR: https://git.openjdk.java.net/jfx/pull/249