Description of problem: I have crash report in msort (1993620), this started in Fedora 34, while Fedora 33 and older works fine. The crash is related to ICU, I get: (gdb) bt #0 0x00007ffff7bfa2a2 in raise () from /lib64/libc.so.6 #1 0x00007ffff7be38a4 in abort () from /lib64/libc.so.6 #2 0x00007ffff5d37a46 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6 #3 0x00007ffff5d4329c in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6 #4 0x00007ffff5d43307 in std::terminate() () from /lib64/libstdc++.so.6 #5 0x00007ffff5d435a9 in __cxa_throw () from /lib64/libstdc++.so.6 #6 0x00007ffff5d3a830 in std::__throw_system_error(int) () from /lib64/libstdc++.so.6 #7 0x00007ffff7df4fff in icu_67::umtx_initImplPreInit(icu_67::UInitOnce&) () from /lib64/libicuuc.so.67 #8 0x00007ffff7e71b77 in icu_67::Norm2AllModes::getNFCInstance(UErrorCode&) () from /lib64/libicuuc.so.67 #9 0x00007ffff7e71bbd in icu_67::Normalizer2::getNFCInstance(UErrorCode&) () from /lib64/libicuuc.so.67 #10 0x00007ffff7e7c10f in unorm_normalize_67 () from /lib64/libicuuc.so.67 #11 0x000055555556542d in NormalizeString (s=s@entry=0x5555555946e0, ResultLength=ResultLength@entry=0x7fffffffd5b8, type=UNORM_NFC) at /export/BUILD/msort-8.53/misc.c:687 #12 0x000055555555ef7d in main (ac=10, av=0x7fffffffda98) at /export/BUILD/msort-8.53/msort.c:1037 Line 687 in msort-8.53/misc.c is: *ResultLength = unorm_normalize(s16,-1,type, 0, NULL, 0, &status); and moves on like this: Result = (UChar*) malloc(sizeof(UChar) * ((*ResultLength) + 1)); if (!Result) { *ResultLength = 0; return NULL; } status = U_ZERO_ERROR; /* Add 1 to *ResultLength to allow addition of terminal null and prevent error code */ CharsNormalized = unorm_normalize(s16, -1,type, 0, Result, (*ResultLength+1), &status); free((void *) s16); if(status != U_ZERO_ERROR) { *ResultLength = -1; return NULL; } So it seems like code does a trick to get length of result, this seems to have worked before, but in Fedora it causes crash as shown above. However, I see ICU version in Fedora 33 and 34 are more or less identical. Do you know any change in ICU which can cause this? Should the code be rrewritten in some way? Thanks for any help.
I added an simple %check section im msort and tried to rebuild in koji for Fedora 34, 35 and rawhide. Fedora 35 and rawhide works: Fedora rawhide https://koji.fedoraproject.org/koji/watchlogs?taskID=75549657 OK Fedora 35: https://koji.fedoraproject.org/koji/watchlogs?taskID=75549666 Ok While Fedora 34 fails: Fedora 34: https://koji.fedoraproject.org/koji/watchlogs?taskID=75549672 Fails { Fedora 33 works too: https://kojipkgs.fedoraproject.org//work/tasks/9988/75549988/build.log Ok } Is something wrong with ICU build in Fedora 34?
I rebuilt ICU 67.1 in Fedora with %global _lto_cflags %nil and then rebuilt msort, this fixed problem Fedora 34. Cou you please consider to rebuild ICU without in Fedora 34. (35 and later seems fine)
ping?
FEDORA-2021-30e528f2d9 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-30e528f2d9
FEDORA-2021-30e528f2d9 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-30e528f2d9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-30e528f2d9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-30e528f2d9 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.