Re: libidn-1.24 validation test problem

[Simon Josefsson]

"Nelson H. F. Beebe" <address@hidden> writes:

> Yesterday afternoon, I started builds of libidn-1.24 in our test lab
> (about 25 flavors of Unix), and this morning, had a look at them.  The
> Mac OS X and Solaris builds all succeeded and passed their validation
> tests.

Thank you for testing!

> However, the SGI IRIX and all GNU/Linux (Alpha, PPC-32, PPC-64, SPARC,
> x86, x86_64) and {Free,Net,Open}BSD builds are hung at this point in
> the validation tests:
>
> ...
> PASS: tst_nfkc
>
> On one x86 system, there is more info:
>
> PASS: tst_nfkc
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --9922-- DWARF2 CFI reader: unhandled CFI instruction 0:10
>
> A check with the top utility show that they have 99% CPU utilization.
> I have therefore installed the successes, and killed all of the
> still-running builds.

The hung processes is because the 'tst_pr29' self-test now tests an
earlier libidn bug where the pr29 functions hang in an infinite loop.
This bug was just fixed.

Thus I believe this is the same problem you saw before with the
tst_idna3 failure: your self-tests are for some reason running with the
system libidn library instead of the newly built one.

Here's another idea: please try running 'make check VALGRIND=' to see if
the problem is caused by valgrind running the self-tests?  Maybe
'valgrind' sets a bad LD_LIBRARY_PATH or something equally weird.
Alternatively, re-run ./configure with --disable-valgrind-tests.

Perhaps valgrind shouldn't be automatically enabled, it has caused a
bunch of problems already and introduces some uncertainty.

/Simon