icu4c-58.1 issues

[ken@…]

Now that we have reverted to icu 57.1, this is a place to list issues / solutions for 58.1.

The killer was the mozilla apps (firefox, seamonkey, thinderbird) which were unusable with 58.1.

I think Pierre found a fix for libreoffice and put it in the book, hopefully it w ill still work with 57.1.

There was also at least one other package which somebody (maybe DJ) mentioned.

[Pierre Labastie]

Well, according to the comment in the patch for libreoffice, I am not sure I shouldn't revert the fix: the patch has the following comment:

+                // ICU 58 made RuleBasedBreakIterator::setBreakType() private
+                // instead of protected, so the old workaround of
+                // https://ssl.icu-project.org/trac/ticket/5498
+                // doesn't work anymore. However, they also claim to have fixed
+                // the cause that an initial fBreakType==-1 would lead to an
+                // endless loop under some circumstances.
+                // Let's see ...

the patch just comments out lines using the SetBreakType() function. But if it is needed for a workaround, it shouldn't be commented out. If I understand correctly the cited ticket, this has been fixed 19 months ago. Was it in 57.1?

[Pierre Labastie]

Changed the summary to let the currency script find the ticket.

[Pierre Labastie]

The segfault in firefox does not come from an API change, but from a regression: The code in ​http://bugs.icu-project.org/trac/ticket/12827 is to be compared to the code in js/src/builtin/Intl.cpp in the FF tree. Using GDB, it can be seen that the segfault is always at line 870 of this file. The relevant lines in this file are:

    840     UErrorCode status = U_ZERO_ERROR;
    841     UEnumeration* values = ucol_getKeywordValuesForLocale("co", locale.ptr(), false, status);
    842     if (U_FAILURE(status)) {
    843         JS_ReportErrorNumber(cx, GetErrorMessage, nullptr, JSMSG_INTERNAL_INTL_ERROR);
    844         return false;
    845     }
    846     ScopedICUObject<UEnumeration> toClose(values, uenum_close);
    847 
    848     uint32_t count = uenum_count(values, &status);
    849     if (U_FAILURE(status)) {
    850         JS_ReportErrorNumber(cx, GetErrorMessage, nullptr, JSMSG_INTERNAL_INTL_ERROR);
    851         return false;
    852     }
    853 
    854     RootedObject collations(cx, NewDenseEmptyArray(cx));
    855     if (!collations)
    856         return false;
    857 
    858     uint32_t index = 0;
    859     for (uint32_t i = 0; i < count; i++) {
    860         const char* collation = uenum_next(values, nullptr, &status);
    861         if (U_FAILURE(status)) {
    862             JS_ReportErrorNumber(cx, GetErrorMessage, nullptr, JSMSG_INT    862 ERNAL_INTL_ERROR);
    863             return false;
    864         }
    865 
    866         // Per ECMA-402, 10.2.3, we don't include standard and search:
    867         // "The values 'standard' and 'search' must not be used as eleme    867 nts in
    868         // any [[sortLocaleData]][locale].co and [[searchLocaleData]][lo    868 cale].co
    869         // array."
    870         if (equal(collation, "standard") || equal(collation, "search"))
    871             continue;

Since uenum_next always returns a NULL, collation is NULL, and the code in line 870 tries to access memory at 0x0, which is forbidden.

I guess the fix is at ​http://bugs.icu-project.org/trac/changeset/39484. Making a patch and testing with firefox

[Pierre Labastie]

Patch in the patch repository under icu4c.

[Pierre Labastie]

ICU4C-58.1 built with the patch: no more segfaults. I am using it right now for writing this comment... I do not know whether other files should be tested. BTW, if somebody has built an app against unpatched ICU-58.1, there is no need to rebuild the app after building patched ICU. Who mentioned other problems with ICU?

[Pierre Labastie]

DJ emailed an answer to the preceding comment: known problems are with sgdisk (from gptfdisk) and possibly with chromium (but right now we use internal ICU, because even ICU-57 does not work). Let me try gptfdisk.

[Pierre Labastie]

I do not see problems with ICU in gptfdisk. It built without error. Actually, form the README:

The ICU library (http://site.icu-project.org), which provides support for
  Unicode partition names, is optional on all platforms except Windows, on
  which it's not supported. Using this library was required to get proper
  UTF-16 partition name support in GPT fdisk versions prior to 0.8.9, but
  as of that version it should not longer be required. Nonetheless, you can
  use it if you're having problems with the new UTF-16 support.[...]

Maybe we should update the book to reflect this fact.

[Pierre Labastie]

Fixed at r17978

[bdubbs@…]

Milestone renamed