Bug 1239574

Created attachment 1047037 [details]
build.log

Created attachment 1047038 [details]
root.log

Created attachment 1047039 [details]
state.log

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.

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..

Even weirder, breaking already in itmajor.cpp:96 callTest( test, par ); I get SIGILL, Illegal instruction.

This is fouled up.

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

(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

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..

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

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.

So gdb is probably fixed, can we try to get this build fixed now?

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.

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

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.

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?

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..

Sigh.. but now..
http://koji.fedoraproject.org/koji/taskinfo?taskID=11163212 f22
http://koji.fedoraproject.org/koji/taskinfo?taskID=11163243 f23
http://koji.fedoraproject.org/koji/taskinfo?taskID=11163352 rawhide