From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 51D7B388A820 for ; Mon, 18 May 2020 10:41:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 51D7B388A820 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-153-sY6vWugmPxWtBe4XU_S0dA-1; Mon, 18 May 2020 06:41:28 -0400 X-MC-Unique: sY6vWugmPxWtBe4XU_S0dA-1 Received: by mail-wm1-f72.google.com with SMTP id a206so2915540wmh.6 for ; Mon, 18 May 2020 03:41:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vwkI92OGE+7XAkEVEx6ZDQt3BYNwe+AjOF3uXY5TvB4=; b=klopyhg7EuEePE4nch9WP9aQAUxzYN6NRs9NruBDC58Qxs67KLlua/YDcLFqfriR8L 4nBSX1J+9E092T+sNS0y/my4/LfOty+5EjUdzEa2U3qsvgbYyMC8xMVZXb4/pWXKU6BA c9E5zTCf0sxh8pIZsj01GK29KFteGFdPkhfSaOQSvZYB5DV2sM6ZHq5Y1g0mk2TIeBW6 PvOM88yCU813iMnDDBrV02NHhiK+iUq7AzVg7w17EI/RHZStAm7SjQdQgTjUPskcCDnF av6WyPcE+yMKJw55sitR+nRB/OyGSYiHtoJPssOcK9f5yp4prMd14eM8psW/mleNOkov k0yQ== X-Gm-Message-State: AOAM533HoNuc+2gt1izYoMgfThfk8sF0Wzlj1EVOzFAhPGYWbkaaaxgr nCrZqvndD9VlKOPDRhnDpBQGeVS5fNOrTMuP+M+ShKdILb+7xM3J40I1oEwmHOJkQ/3hVX4s351 EdiBuIKmSMK45uAbWomsB4Q== X-Received: by 2002:a05:6000:128b:: with SMTP id f11mr19135080wrx.227.1589798487032; Mon, 18 May 2020 03:41:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDLTSEaDNLrbRayUCx+tr5x6X00qSoPjdezKRaQa7uRp+XUUYp02oOKbWTKkAVaCwPiv6/uw== X-Received: by 2002:a05:6000:128b:: with SMTP id f11mr19135058wrx.227.1589798486858; Mon, 18 May 2020 03:41:26 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 18sm15655733wmj.19.2020.05.18.03.41.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 03:41:26 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Warn about leaked global array To: Tom de Vries , "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" References: <20200513205338.14233-1-palves@redhat.com> <20200513205338.14233-7-palves@redhat.com> <0d00b418-3c5f-4a8c-12dd-eeee8ad12b6b@suse.de> <4ade3da1-a8cd-ba29-80da-f5e742f7b52a@palves.net> <7d7a056c-63cb-1865-b8ab-027840ac15bc@redhat.com> <0bd64ab2-e736-2dbc-5fc2-99b32a44d670@redhat.com> <5c3d667e-7a88-0de6-6a19-6b3c4a9130e4@suse.de> From: Pedro Alves Message-ID: <67c6dcab-f83c-3792-d2c3-63ef8e38b0ec@redhat.com> Date: Mon, 18 May 2020 11:41:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <5c3d667e-7a88-0de6-6a19-6b3c4a9130e4@suse.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 10:41:31 -0000 On 5/18/20 7:18 AM, Tom de Vries wrote: > I managed to find a better way of dealing with this, using "upvar #0". > I've also added more comments to the patch. Cool. > +# Check global variables not in gdb_global_vars. > + > +proc check_global_vars { } { > + # Sample state after running test. > + global gdb_global_vars > + set vars [info globals] > + > + # I'm not sure these two should actually be global, but at least there > + # seems to be no harm in having these as globals, given that we don't > + # expect to reuse these names as scalars. > + set skip [list "expect_out" "spawn_out"] They can be local or global. See man expect: Expect takes a rather liberal view of scoping. In particular, variables read by commands specific to the Expect program will be sought first from the local scope, and if not found, in the global scope. For example, this obviates the need to place "global timeout" in every procedure you write that uses expect. On the other hand, variables written are always in the local scope (unless a "global" command has been issued). The most common problem this causes is when spawn is executed in a procedure. Outside the procedure, spawn_id no longer exists, so the spawned process is no longer accessible simply because of scoping. Add a "global spawn_id" to such a procedure. For example, mi_gdb_test does: proc mi_gdb_test { args } { global verbose global mi_gdb_prompt global GDB expect_out ^^^^^^^^^^ global inferior_exited_re async upvar timeout timeout and then gdb.mi/mi-basics.exp does: proc test_path_specification {} { ... global expect_out ... mi_gdb_test "-environment-path" "\\\^done,path=\"(.*)\"" "environment-path" set orig_path $expect_out(3,string) ... So making expect_out global allows gdb.mi/mi-basics.exp to reference it. We could alternatively switch mi_gdb_test (and whatever other procedure does a similar thing) to doing "upvar expect_out expect_out" and get rid of "global expect_out". Not sure it's worth the bother. > + global gdb_test_file_name > + warning "$gdb_test_file_name.exp defined global array $var" > + > + # If the variable remains set, we won't warn for the next test where > + # it's leaked, so unset. > + global_unset $var Tabs / spaces above. Thanks, Pedro Alves