From: Pedro Alves <palves@redhat.com>
To: Tom de Vries <tdevries@suse.de>,
"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH][gdb/testsuite] Warn about leaked global array
Date: Mon, 18 May 2020 11:41:25 +0100 [thread overview]
Message-ID: <67c6dcab-f83c-3792-d2c3-63ef8e38b0ec@redhat.com> (raw)
In-Reply-To: <5c3d667e-7a88-0de6-6a19-6b3c4a9130e4@suse.de>
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
next prev parent reply other threads:[~2020-05-18 10:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 20:53 [PATCH v8 0/6] Handle already-exited threads in 'stop_all_threads' Pedro Alves
2020-05-13 20:53 ` [PATCH v8 1/6] gdb: protect some 'regcache_read_pc' calls Pedro Alves
2020-05-13 20:53 ` [PATCH v8 2/6] gdb/infrun: move a 'regcache_read_pc' call down to first use Pedro Alves
2020-05-13 20:53 ` [PATCH v8 3/6] gdb/infrun: extract out a code piece into 'mark_non_executing_threads' function Pedro Alves
2020-05-13 20:53 ` [PATCH v8 4/6] gdb: introduce 'all_non_exited_process_targets' and 'switch_to_target_no_thread' Pedro Alves
2020-05-14 8:44 ` Aktemur, Tankut Baris
2020-05-14 11:12 ` Pedro Alves
2020-05-14 11:23 ` Aktemur, Tankut Baris
2020-05-13 20:53 ` [PATCH v8 5/6] gdb/infrun: enable/disable thread events of all targets in stop_all_threads Pedro Alves
2020-05-14 8:44 ` Aktemur, Tankut Baris
2020-05-14 11:16 ` Pedro Alves
2020-05-14 11:30 ` Aktemur, Tankut Baris
2020-05-13 20:53 ` [PATCH v8 6/6] gdb/infrun: handle already-exited threads when attempting to stop Pedro Alves
2020-05-14 8:47 ` Aktemur, Tankut Baris
2020-05-14 11:16 ` Pedro Alves
2020-05-14 11:40 ` Aktemur, Tankut Baris
2020-05-14 18:00 ` Tom de Vries
2020-05-14 18:54 ` Aktemur, Tankut Baris
2020-05-14 18:58 ` Pedro Alves
2020-05-15 7:53 ` Aktemur, Tankut Baris
2020-05-15 10:14 ` Pedro Alves
2020-05-15 10:17 ` Tom de Vries
2020-05-15 10:35 ` Pedro Alves
2020-05-15 11:53 ` Tom de Vries
2020-05-15 12:02 ` Pedro Alves
2020-05-15 14:16 ` Tom de Vries
2020-05-15 15:46 ` Pedro Alves
2020-05-15 17:17 ` Tom de Vries
2020-05-18 6:18 ` [PATCH][gdb/testsuite] Warn about leaked global array Tom de Vries
2020-05-18 10:41 ` Pedro Alves [this message]
2020-05-19 16:34 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67c6dcab-f83c-3792-d2c3-63ef8e38b0ec@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tankut.baris.aktemur@intel.com \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox