From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1490 invoked by alias); 19 Feb 2010 17:24:00 -0000 Received: (qmail 1477 invoked by uid 22791); 19 Feb 2010 17:24:00 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Feb 2010 17:23:56 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1JHNsEo003342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 19 Feb 2010 12:23:54 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1JHNrnr018114; Fri, 19 Feb 2010 12:23:54 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o1JHNq30025061; Fri, 19 Feb 2010 12:23:53 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 738EC378212; Fri, 19 Feb 2010 10:23:52 -0700 (MST) From: Tom Tromey To: gdb-patches@sourceware.org Subject: RFA: valgrind and the test suite, take 2 Reply-To: Tom Tromey Date: Fri, 19 Feb 2010 17:24:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00491.txt.bz2 This needs a documentation review. I would also appreciate other comments, as usual. This patch adds support for valgrind to the test suite. Unlike my last patch along these lines, this one adds value above just setting GDB. In particular, it adds a new test at each point where the tested gdb exits. If that gdb run caused valgrind to log any errors, the test fails. I ran the entire test suite this way on the compile farm and found a number of problems (perhaps not all of our causing ... I'm still sorting through the logs). Tom 2010-02-19 Tom Tromey * gdbint.texinfo (Testsuite): Document use of VALGRIND setting. 2010-02-19 Tom Tromey * lib/gdb.exp: Recognize VALGRIND variable. (remote_spawn): New wrapper proc. (gdb_exit): Likewise. diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index 7741855..8b02ed8 100644 --- a/gdb/doc/gdbint.texinfo +++ b/gdb/doc/gdbint.texinfo @@ -7674,6 +7674,19 @@ HOME=`pwd` runtest \ INTERNAL_GDBFLAGS=-nw @end smallexample +@item @code{VALGRIND} + +It is useful to occasionally run @value{GDBN} under @code{valgrind}, +to find bugs that do not always result in an immediate failure. This +can be accomplished by setting @code{VALGRIND}. The contents of this +will be appended to the internal @code{valgrind} command line that the +test suite computes. @code{VALGRIND} can be empty. + +Setting this will add an additional check; each time @value{GDBN} +exits, the contents of a the @code{valgrind} log file are examined +and, if there was any output, the @samp{valgrind check} test will +fail. + @end itemize There are two ways to run the testsuite and pass additional parameters diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index a42d551..7bf1ea9 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -42,6 +42,14 @@ if ![info exists GDB] { } verbose "using GDB = $GDB" 2 +# If VALGRIND is set, we run gdb under valgrind. +if {[info exists VALGRIND]} { + global outdir env vg_basename + set env(VGNAME) 0 + set vg_basename "$outdir/valgrind." + set GDB "valgrind --quiet --trace-children=no --child-silent-after-fork=yes --log-file=${vg_basename}%q{VGNAME} $VALGRIND $GDB" +} + # GDBFLAGS is available for the user to set on the command line. # E.g. make check RUNTESTFLAGS=GDBFLAGS=mumble # Testcases may use it to add additional flags, but they must: @@ -3139,6 +3147,50 @@ if {[info exists TRANSCRIPT]} { } } +# Support for running gdb under valgrind and checking the results. +if {[info exists VALGRIND]} { + rename remote_spawn vg_remote_spawn + rename gdb_exit vg_gdb_exit + + proc remote_spawn {args} { + global env vg_basename + incr env(VGNAME) + file delete -force ${vg_basename}$env(VGNAME) + return [uplevel vg_remote_spawn $args] + } + + proc gdb_exit {args} { + global env vg_basename vg_reported + + # We can sometimes see multiple consecutive calls to gdb_exit + # without an intervening spawn. In this case we only want to + # report the valgrind results once. + if {![info exists vg_reported($env(VGNAME))]} { + set vg_reported($env(VGNAME)) 1 + + # FIXME: how can we name this test consistently across + # runs? + if {[file exists ${vg_basename}$env(VGNAME)] + && [file size ${vg_basename}$env(VGNAME)] > 0} { + send_log "Valgrind output:\n" + set fd [open ${vg_basename}$env(VGNAME)] + send_log [read $fd] + close $fd + send_log "\n" + fail "valgrind check $env(VGNAME)" + } else { + pass "valgrind check $env(VGNAME)" + } + } + + return [uplevel vg_gdb_exit $args] + } + + # Valgrind slows everything down, so boost the default timeout. + global gdb_test_timeout + set gdb_test_timeout [expr {20 * $gdb_test_timeout}] +} + proc core_find {binfile {deletefiles {}} {arg ""}} { global objdir subdir