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 E08CA386F44A for ; Mon, 18 May 2020 06:18:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E08CA386F44A 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 A8961B15D; Mon, 18 May 2020 06:18:34 +0000 (UTC) Subject: [PATCH][gdb/testsuite] Warn about leaked global array From: Tom de Vries 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> 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: <5c3d667e-7a88-0de6-6a19-6b3c4a9130e4@suse.de> Date: Mon, 18 May 2020 08:18:28 +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: Content-Type: multipart/mixed; boundary="------------4C86FDB7A9E32ED1040D1BB2" Content-Language: en-US X-Spam-Status: No, score=-18.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, 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: Mon, 18 May 2020 06:18:34 -0000 This is a multi-part message in MIME format. --------------4C86FDB7A9E32ED1040D1BB2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ was: Re: [PATCH v8 6/6] gdb/infrun: handle already-exited threads when attempting to stop ] On 15-05-2020 19:17, Tom de Vries wrote: > On 15-05-2020 17:46, Pedro Alves wrote: >> Curious -- is there a reason for the underscores? >> > > Yeah, I'm trying to avoid this: > ... > $ cat test.tcl > #!/usr/bin/tclsh > > proc foo { var } { > global $var > } > > foo var > $ ./test.tcl > variable "var" already exists > while executing > "global $var" > (procedure "foo" line 2) > invoked from within > "foo var" > (file "./test.tcl" line 7) > ... I managed to find a better way of dealing with this, using "upvar #0". I've also added more comments to the patch. Thanks, - Tom --------------4C86FDB7A9E32ED1040D1BB2 Content-Type: text/x-patch; charset=UTF-8; name="0001-gdb-testsuite-Warn-about-leaked-global-array.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-gdb-testsuite-Warn-about-leaked-global-array.patch" [gdb/testsuite] Warn about leaked global array A variable name cannot be used both as scalar and array without an intermediate unset. Trying to do so will result in tcl errors, for example, for: ... set var "bla" set var(1) "bla" ... we get: ... can't set "var(1)": variable isn't array ... and for the reverse statement order we get: ... can't set "var": variable is array ... So, since a global name in one test-case can leak to another test-case, setting a global name in one test-case can result in a tcl error in another test-case that reuses the name in a different way. Warn about leaking a global array from a test-case. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-18 Tom de Vries * lib/gdb.exp (global_array_exists, global_unset, save_global_vars) (check_global_vars): New proc. (gdb_init): Call save_global_vars. (gdb_finish): Call check_global_vars. --- gdb/testsuite/lib/gdb.exp | 91 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index f7d20bd94f..285736ee92 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -5048,6 +5048,95 @@ proc standard_testfile {args} { } } +# Returns 1 if GLOBALVARNAME is a global array. + +proc global_array_exists { globalvarname } { + # Introduce local alias of global variable $globalvarname. Using + # "global $globalvarname" instead is simpler, but this may result in a + # clash with local name "globalvarname". + upvar #0 $globalvarname globalvar + return [array exists globalvar] +} + +# Unset global variable GLOBALVARNAME. + +proc global_unset { globalvarname } { + # Introduce local alias of global variable $globalvarname. + upvar #0 $globalvarname globalvar + unset globalvar +} + +# Save global vars to variable gdb_global_vars. + +proc save_global_vars { test_file_name } { + # Save for the warning. + global gdb_test_file_name + set gdb_test_file_name $test_file_name + + # Sample state before running test. + global gdb_global_vars + set gdb_global_vars [info globals] +} + +# 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"] + + foreach var $vars { + if { ![global_array_exists $var] } { + continue + } + + set found [lsearch -exact $gdb_global_vars $var] + if { $found != -1 } { + # Already present before running test. + continue + } + + set found [lsearch -exact $skip $var] + if { $found != -1 } { + continue + } + + # A variable name cannot be used both as scalar and array without an + # intermediate unset. Trying to do so will result in tcl errors, for + # example, for: + # set var "bla" + # set var(1) "bla" + # we get: + # can't set "var(1)": variable isn't array + # and for the reverse statement order we get: + # can't set "var": variable is array + # + # So, since a global name in one test-case can leak to another + # test-case, setting a global name in one test-case can result in + # a tcl error in another test-case that reuses the name in a different + # way. + # + # Warn about leaking a global array from the test-case. + # The way to fix this is to wrap the test-case in a namespace and to + # change the global variable into a namespace variable: + # namespace eval $testfile { + # variable var + # ... + # } + 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 + } +} + # The default timeout used when testing GDB commands. We want to use # the same timeout as the default dejagnu timeout, unless the user has # already provided a specific value (probably through a site.exp file). @@ -5177,10 +5266,12 @@ proc gdb_init { test_file_name } { global gdb_instances set gdb_instances 0 + save_global_vars $test_file_name return [default_gdb_init $test_file_name] } proc gdb_finish { } { + check_global_vars global gdbserver_reconnect_p global gdb_prompt global cleanfiles --------------4C86FDB7A9E32ED1040D1BB2--