This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdb.threads/thread-specific.exp: Fix uninitialized variable references
- From: Pedro Alves <palves at redhat dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 20 Mar 2014 11:24:50 +0000
- Subject: Re: [PATCH] gdb.threads/thread-specific.exp: Fix uninitialized variable references
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1403070229280 dot 23119 at tp dot orcam dot me dot uk>
On 03/07/2014 02:37 PM, Maciej W. Rozycki wrote:
> Hi,
>
> This fixes:
>
> FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout)
> ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/thread-specific.exp.
> ERROR: can't read "this_breakpoint": no such variable
> while executing
> "gdb_test_multiple "info breakpoint $this_breakpoint" "info on bp" {
> -re ".*stop only in thread (\[0-9\]*).*$gdb_prompt $" {
> set this_thread $expe..."
> (file ".../gdb/testsuite/gdb.threads/thread-specific.exp" line 108)
> invoked from within
> "source .../gdb/testsuite/gdb.threads/thread-specific.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source .../gdb/testsuite/gdb.threads/thread-specific.exp"
> invoked from within
> "catch "uplevel #0 source $test_file_name""
>
> and then:
>
> FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout)
> UNTESTED: gdb.threads/thread-specific.exp: info on bp
> ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/thread-specific.exp.
> ERROR: can't read "this_thread": no such variable
> while executing
> "gdb_test {print $_thread} ".* = $this_thread" "thread var at break""
> (file ".../gdb/testsuite/gdb.threads/thread-specific.exp" line 119)
> invoked from within
> "source .../gdb/testsuite/gdb.threads/thread-specific.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source .../gdb/testsuite/gdb.threads/thread-specific.exp"
> invoked from within
> "catch "uplevel #0 source $test_file_name""
>
> Final results:
>
> FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout)
> UNTESTED: gdb.threads/thread-specific.exp: info on bp
> UNTESTED: gdb.threads/thread-specific.exp: thread var at break
>
> Of course the first failure best wasn't there, but failing that the script
> shouldn't crash.
>
> OK to apply?
Thanks! Close, but needs a little tweak.
Using "info exists" uses like this isn't safe, given that
in a single dejagnu run that tests multiple .exp test files (like just
plain "make check"), global variables set in previous test files leak
into the current test file. So what we usually do instead is set
the variable unconditionally upfront to some invalid value, and
then compare against that value. E.g.:
set this_breakpoint -1
gdb_test_multiple "continue" "continue to thread-specific breakpoint" {
-re "Breakpoint $main_breakpoint, .* at .*\r\n$gdb_prompt $" {
fail "continue to thread-specific breakpoint (wrong breakpoint)"
}
-re "Breakpoint (\[0-9\]*), .* at .*\r\n$gdb_prompt $" {
set this_breakpoint $expect_out(1,string)
pass "continue to thread-specific breakpoint"
}
}
if { $this_breakpoint == -1 } {
untested ...
} else {
...
}
Of course we could unset the variable instead of setting it
to -1, using 'unset -nocomplain'. Same thing. Somehow I'm
inclined to think that pattern is more prone to copy-paste
forgetting to do the unset though, but I'd be fine with it.
--
Pedro Alves