This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Spurious libstdc++ testsuite failures because of truncated buffered output


On Fri, Mar 18, 2011 at 11:30, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi
>>
>> I am getting several failures in decimal/mixed-mode_neg.cc:
>>
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 195)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 196)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 197)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 198)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 199)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 200)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 201)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 202)
>> FAIL: decimal/mixed-mode_neg.cc Â(test for errors, line 203)
>>
>> This test expects syntax errors in all these lines, and the compiler
>> is indeed flagging them but the output from the compiler is so big
>> that dejagnu truncates it. ÂThe testsuite never sees the error
>> messages starting at line 195 (I can see the output truncated in
>> libstdc++.log).
>>
>> Is there a way to increase dejagnu's buffering? ÂThis does not happen,
>> if I simply run the build in a shallower build tree, but that is not a
>> viable alternative.
>
> Honestly, I know very little about the dejagnu buffering, but I'm having a
> quick look to the issue and I'm rather surprised that you are seeing it for
> these particular errors and nowhere else in the testsuite: here, on the
> libstdc++.log of x86_64-linux, I see just 9 candidates listed, and I'm
> pretty sure that in terms of error messages we have much, much, longer
> examples, when templates are involved in particular. What I'm missing?

I don't really know why the others don't fail, but I will take a look.
 In this particular case, the output is truncated after 1,032,134
bytes are printed.  So I can only speculate that no other tests
generate more than this number of bytes in output.  I'll take a look.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]