Bug 1239574 - icu: FTBFS in rawhide
Summary: icu: FTBFS in rawhide
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: icu
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Eike Rathke
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
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)

(edit)
Clone Of:
(edit)
Last Closed: 2015-11-04 11:35:31 UTC


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.

http://koji.fedoraproject.org/koji/taskinfo?taskID=10097469

For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

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

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

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

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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

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.

<https://sourceware.org/ml/gdb-patches/2015-08/msg00629.html>

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:

gdb-7.9.1-18.fc22
gdb-7.10-17.fc23

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) );
to
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:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11138619 f22
http://koji.fedoraproject.org/koji/taskinfo?taskID=11138625 f23
http://koji.fedoraproject.org/koji/taskinfo?taskID=11138629 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.