This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gdb.threads/thread-specific.exp: Fix uninitialized variable references


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]