Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1239574 - icu: FTBFS in rawhide
Summary: icu: FTBFS in rawhide
Alias: None
Product: Fedora
Classification: Fedora
Component: icu
Version: 23
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Eike Rathke
QA Contact: Fedora Extras Quality Assurance
Depends On: 1196181
Blocks: ARMTracker F23FTBFS
TreeView+ depends on / blocked
Reported: 2015-07-05 21:00 UTC by Dennis Gilmore
Modified: 2015-11-04 11:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-04 11:35:31 UTC
Type: ---

Attachments (Terms of Use)
build.log (431.12 KB, text/plain)
2015-07-05 21:00 UTC, Dennis Gilmore
no flags Details
root.log (70.45 KB, text/plain)
2015-07-05 21:00 UTC, Dennis Gilmore
no flags Details
state.log (601 bytes, text/plain)
2015-07-05 21:00 UTC, Dennis Gilmore
no flags Details

Description Dennis Gilmore 2015-07-05 21:00:29 UTC
Your package icu failed to build from source in current rawhide.

For details on mass rebuild see

Comment 1 Dennis Gilmore 2015-07-05 21:00:31 UTC
Created attachment 1047037 [details]

Comment 2 Dennis Gilmore 2015-07-05 21:00:32 UTC
Created attachment 1047038 [details]

Comment 3 Dennis Gilmore 2015-07-05 21:00:32 UTC
Created attachment 1047039 [details]

Comment 4 Eike Rathke 2015-07-06 12:24:13 UTC
So, can anyone provide me with a login to an armv7hl F23 machine? The failure is in some (not all) scientific number format tests and I assume an error due to compile time optimization or some such as it works on all other platforms. Without hands-on debugging it is impossible to tell.

Comment 5 Eike Rathke 2015-07-14 20:43:09 UTC
Btw also happens when building master on armv7hl F22.

Great fun.. running intltest some format tests fail, running  intltest format  for the format tests only there is no failure. Running in the debugger with a breakpoint on one of the failing tests NumberFormatTest::TestExponential() there's a SIGSEGV on the errcheckln() line *after* the breakpoint before hitting it.

This smells..

Comment 6 Eike Rathke 2015-07-14 20:55:22 UTC
Even weirder, breaking already in itmajor.cpp:96 callTest( test, par ); I get SIGILL, Illegal instruction.

This is fouled up.

Comment 7 Jan Kurik 2015-07-15 13:40:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 8 Peter Robinson 2015-08-18 15:35:38 UTC
(In reply to Eike Rathke from comment #5)
> Btw also happens when building master on armv7hl F22.

If you have an issue with ARMv7 builds please add it to ARMTracker so we are aware of the issue or communicate via IRC/lists. There are ARM machines available in beaker and via Fedora QA, alternatively if it's in the ARM tracker it's possible we can provide other alternatives. 

If we are unaware of an issue I'm not sure how we're expected to help

Comment 9 Eike Rathke 2015-08-19 10:22:26 UTC
Sorry, yes, I thought I'd find a solution other than disabling the tests.
I tried on a machine in Beaker earlier, had it run with valgrind first that spat out millions of uninitialized, not a real help. Also tried debugging a simple "hello world", which wasn't possible, when hitting a breakpoint gdb says "Cannot parse expression `.L976 4@r4'."

So, I can disable tests temporarily to provide a build, but I somewhat wouldn't trust the result..

Comment 10 Peter Robinson 2015-08-19 11:28:19 UTC
It might be worth disabling them temporarily, the GDB issue is known (added as a dep), and leaving this bug open to track the issue to completion for re-enabling the tests

Comment 11 Sergio Durigan Junior 2015-08-22 00:36:28 UTC
I posted a patch to GDB that should workaround this issue.


Once it has been discussed upstream, I intend to backport it to Fedora GDB.

Comment 12 Peter Robinson 2015-09-08 21:50:16 UTC
So gdb is probably fixed, can we try to get this build fixed now?

Comment 13 Eike Rathke 2015-09-09 10:14:24 UTC
Ok, I'll try another round wrestling with arm.. if nothing helps then I'll disable the tests in question to provide a build.

Is gdb fixed only in f23 or also in f22? Because I encountered the same problem in f22.

Comment 14 Peter Robinson 2015-09-09 10:55:19 UTC
From the blocking bug:

So, I've just pushed two updates to Fedora GDB that should workaround this problem:


Comment 15 Eike Rathke 2015-09-17 22:05:00 UTC
This gets even weirder.. installed gdb-7.9.1-18.fc22 from updates-testing.
After  fedpkg local  has built icu, cd icu/source/test/intltest and execute

LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ./intltest format/NumberFormatSpecificationTest/TestScientificNotation

where  LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ./intltest  is what is executed from within make to pull in the proper libs.
This repeatable produces the same 5 errors

FAIL: ; got "12,300E3"; expected "123,00E2" - (Are you missing data?)
FAIL: ; got "12,30E3"; expected "123,0E2"
FAIL: ; got "12,30E3"; expected "123,0E2"
FAIL: ; got "12,301E3"; expected "123,01E2"
FAIL: ; got "12,301E+03"; expected "123,01E+02"

Running the same within gdb like

LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH gdb --args ./intltest format/NumberFormatSpecificationTest/TestScientificNotation

and having set a breakpoint numfmtspectest.cpp:133 (which is the assertPatternFr("123,00E2", 12300.0, "000.00E0", TRUE) line)

also produces 5 errors, but the breakpoint is not hit and each time for the first error there's arbitrary data involved, for example

FAIL: ; got "B\u00C1\u030112300"; expected "123,00E2" - (Are you missing data?)
instead of
FAIL: ; got "12,300E3"; expected "123,00E2" - (Are you missing data?)

That does not happen if the breakpoint is disabled.

Setting a breakpoint on line 132 instead the program terminates with SIGSEGV in IntlTest::logln() of intltest.cpp:949, which is below the assertPatternFr() of NumberFormatSpecificationTest::TestScientificNotation().

I suspect gdb garbles the stack when a breakpoint is set.

Comment 16 Eike Rathke 2015-09-18 12:14:02 UTC
To verify that none of the last two commits is the culprit I rolled back to 54.1-1 which was the last version built for f22-armv7hl and currently is installed from the repository. That one also fails to build. So the cause apparently is something that changed in the tool chain after 2015-01-26, like a new compiler version.

The fault is quite easily reproducible after fedpkg local build by
cd icu/source/test/cintltst
LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ./cintltst /tsformat/cnmdptst/TestExponential

Interestingly, omitting the LD_LIBRARY_PATH and executing
./cintltst /tsformat/cnmdptst/TestExponential
the test does not fail, i.e. when the installed system libraries are used by the test.

Modifying the corresponding test values in cnmdptst.c TestExponential() line 210 in this case (opposed to the ones in source/test/intltest/numfmtst.cpp NumberFormatTest::TestExponential()) doesn't even help, or I didn't figure out what exact value is needed. Trying to output the actual result by modifying line 311
log_err("FAIL: Expected %s ( %s )\n", valFormat[v+ilval], austrdup(ulvalfor) );
log_err("FAIL: Expected %s ( %s ) Got %s\n", valFormat[v+ilval], austrdup(ulvalfor), austrdup(str) );
didn't work because the output of str was a format mask instead of the actual result string. WTF?

Might it be that in some cases parameter arguments on the stack are messed around with?

Comment 17 Eike Rathke 2015-09-18 18:50:25 UTC
Workaround disabling offending tests on armv7hl building: f22 f23 f24/rawhide

This is NOT a solution, but..

Note You need to log in before you can comment on or make changes to this bug.