From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id E8B4C3840C2A for ; Tue, 19 May 2020 16:34:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E8B4C3840C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B749BADD2; Tue, 19 May 2020 16:34:55 +0000 (UTC) Subject: Re: [PATCH][gdb/testsuite] Warn about leaked global array To: Pedro Alves , "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> <67c6dcab-f83c-3792-d2c3-63ef8e38b0ec@redhat.com> From: Tom de Vries Autocrypt: addr=tdevries@suse.de; keydata= xsBNBF0ltCcBCADDhsUnMMdEXiHFfqJdXeRvgqSEUxLCy/pHek88ALuFnPTICTwkf4g7uSR7 HvOFUoUyu8oP5mNb4VZHy3Xy8KRZGaQuaOHNhZAT1xaVo6kxjswUi3vYgGJhFMiLuIHdApoc u5f7UbV+egYVxmkvVLSqsVD4pUgHeSoAcIlm3blZ1sDKviJCwaHxDQkVmSsGXImaAU+ViJ5l CwkvyiiIifWD2SoOuFexZyZ7RUddLosgsO0npVUYbl6dEMq2a5ijGF6/rBs1m3nAoIgpXk6P TCKlSWVW6OCneTaKM5C387972qREtiArTakRQIpvDJuiR2soGfdeJ6igGA1FZjU+IsM5ABEB AAHNH1RvbSBkZSBWcmllcyA8dGRldnJpZXNAc3VzZS5kZT7CwKsEEwEIAD4WIQSsnSe5hKbL MK1mGmjuhV2rbOJEoAUCXSW0JwIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAh CRDuhV2rbOJEoBYhBKydJ7mEpsswrWYaaO6FXats4kSgc48H/Ra2lq5p3dHsrlQLqM7N68Fo eRDf3PMevXyMlrCYDGLVncQwMw3O/AkousktXKQ42DPJh65zoXB22yUt8m0g12xkLax98KFJ 5NyUloa6HflLl+wQL/uZjIdNUQaHQLw3HKwRMVi4l0/Jh/TygYG1Dtm8I4o708JS4y8GQxoQ UL0z1OM9hyM3gI2WVTTyprsBHy2EjMOu/2Xpod95pF8f90zBLajy6qXEnxlcsqreMaqmkzKn 3KTZpWRxNAS/IH3FbGQ+3RpWkNGSJpwfEMVCeyK5a1n7yt1podd1ajY5mA1jcaUmGppqx827 8TqyteNe1B/pbiUt2L/WhnTgW1NC1QDOwE0EXSW0JwEIAM99H34Bu4MKM7HDJVt864MXbx7B 1M93wVlpJ7Uq+XDFD0A0hIal028j+h6jA6bhzWto4RUfDl/9mn1StngNVFovvwtfzbamp6+W pKHZm9X5YvlIwCx131kTxCNDcF+/adRW4n8CU3pZWYmNVqhMUiPLxElA6QhXTtVBh1RkjCZQ Kmbd1szvcOfaD8s+tJABJzNZsmO2hVuFwkDrRN8Jgrh92a+yHQPd9+RybW2l7sJv26nkUH5Z 5s84P6894ebgimcprJdAkjJTgprl1nhgvptU5M9Uv85Pferoh2groQEAtRPlCGrZ2/2qVNe9 XJfSYbiyedvApWcJs5DOByTaKkcAEQEAAcLAkwQYAQgAJhYhBKydJ7mEpsswrWYaaO6FXats 4kSgBQJdJbQnAhsMBQkDwmcAACEJEO6FXats4kSgFiEErJ0nuYSmyzCtZhpo7oVdq2ziRKD3 twf7BAQBZ8TqR812zKAD7biOnWIJ0McV72PFBxmLIHp24UVe0ZogtYMxSWKLg3csh0yLVwc7 H3vldzJ9AoK3Qxp0Q6K/rDOeUy3HMqewQGcqrsRRh0NXDIQk5CgSrZslPe47qIbe3O7ik/MC q31FNIAQJPmKXX25B115MMzkSKlv4udfx7KdyxHrTSkwWZArLQiEZj5KG4cCKhIoMygPTA3U yGaIvI/BGOtHZ7bEBVUCFDFfOWJ26IOCoPnSVUvKPEOH9dv+sNy7jyBsP5QxeTqwxC/1ZtNS DUCSFQjqA6bEGwM22dP8OUY6SC94x1G81A9/xbtm9LQxKm0EiDH8KBMLfQ== Message-ID: <9b35c7f0-11cb-8d55-085e-b5dd0c70de52@suse.de> Date: Tue, 19 May 2020 18:34:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <67c6dcab-f83c-3792-d2c3-63ef8e38b0ec@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Tue, 19 May 2020 16:34:56 -0000 On 18-05-2020 12:41, Pedro Alves wrote: > 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. > OK, that's helpful, thanks for the info. >> + 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. > Fixed, and resubmitted as part of a patch series that also includes warning fixes here ( https://sourceware.org/pipermail/gdb-patches/2020-May/168771.html ). Also, fixing the warnings turned out to be more complicated than I thought, so I ended up moving the bit about how to fix the warning into a gdb/testsuite/README section (part of patch 2/3). Thanks, - Tom