From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20888 invoked by alias); 18 Mar 2011 15:36:07 -0000 Received: (qmail 20823 invoked by uid 22791); 18 Mar 2011 15:36:06 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Mar 2011 15:35:59 +0000 Received: from eggs.gnu.org ([140.186.70.92]:47573) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Q0biX-0000qM-DS for gcc@gnu.org; Fri, 18 Mar 2011 11:35:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0biW-0004ec-A9 for gcc@gnu.org; Fri, 18 Mar 2011 11:35:57 -0400 Received: from smtp-out.google.com ([216.239.44.51]:49888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0biV-0004eX-U9 for gcc@gnu.org; Fri, 18 Mar 2011 11:35:56 -0400 Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p2IFZshL021531 for ; Fri, 18 Mar 2011 08:35:55 -0700 Received: from vxb39 (vxb39.prod.google.com [10.241.33.103]) by kpbe19.cbf.corp.google.com with ESMTP id p2IFYaod027896 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 18 Mar 2011 08:35:53 -0700 Received: by vxb39 with SMTP id 39so3867935vxb.12 for ; Fri, 18 Mar 2011 08:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.68 with SMTP id x4mr330973vcr.244.1300462553122; Fri, 18 Mar 2011 08:35:53 -0700 (PDT) Received: by 10.220.16.129 with HTTP; Fri, 18 Mar 2011 08:35:53 -0700 (PDT) In-Reply-To: <4D837A7B.8020005@oracle.com> References: <4D837A7B.8020005@oracle.com> Date: Fri, 18 Mar 2011 15:36:00 -0000 Message-ID: Subject: Re: Spurious libstdc++ testsuite failures because of truncated buffered output From: Diego Novillo To: Paolo Carlini Cc: gcc@gnu.org, libstdc++@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 216.239.44.51 X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00264.txt.bz2 On Fri, Mar 18, 2011 at 11:30, Paolo Carlini wro= te: > Hi >> >> I am getting several failures in decimal/mixed-mode_neg.cc: >> >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 195) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 196) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 197) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 198) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 199) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 200) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 201) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(test for errors, line 202) >> FAIL: decimal/mixed-mode_neg.cc =C2=A0(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. =C2=A0The 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? =C2=A0This does not happ= en, >> 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 f= or > 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.