Re: Test failure: 22_locale/locale/cons/12352.cc

[Paolo Carlini <pcarlini at suse dot de>]

Hi,

> The test "22_locale/locale/cons/12352.cc" fails on some platforms
> reliably.  No indication is given what the problem is other than a
> "status 9" in our journal.  The platforms in question are ultimately
> derived from Debian 3.1 via the DCC platform, and neither Debian nor DCC
> fail the test.
>  
It looks like the availability of that specific platform is a 
prerequisite to debug the issue: I don't know how many regular 
contributors and maintainers of libstdc++ have it available... Anyway, I 
can confirm that the test always passes for many different targets and 
versions of the various OSes, as you can see on testresults (from time 
to time a specific poster sends  failures on s390x-linux, but in fact 
cannot be reproduced by Ulrich Weigand, probably that setup is broken 
somehow as regards the localedata). Personally, I never saw it failing 
on all the machines I have available. The original issue in 12352 was a 
memory leak, and indeed we are not seeing it anymore (I would suggest 
valgrind here).

> Attaching strace to the test process shows that the test seems to be
> hung on a kernel futex call.  Attaching gdb shows some very odd results;
> gdb can't get to many of the automatic variables, or even function call
> parameters, but the stack trace looks right otherwise, and the number of
> iteration is negative even though the code checks for and disallows
> that.
>  
I see, puzzling. A few trivial suggestions: building the testcase -O0 
-g3 helps the debugger *a lot* (we always do that in our daily work, 
when debugging), playing a bit with the optimization level and switches 
also helps in figuring out miscompilations (always possible, in 
principle) and other problems in the code (like uninitialized variables, 
etc.). Another thought, you can try replacing locale("") with a specific 
locale, known to work well on that machine, like, f.i., "de_DE", 
"fr_FR", anything can do besides the C locale (which leads to different 
memory allocations patterns).

Paolo.