Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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



  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