FYI: fixlet for linux-dp.exp

FYI: fixlet for linux-dp.exp

[Tom Tromey]

I'm checking this in.

While running the test suite I got:

ERROR: tcl error sourcing ../../../archer/gdb/testsuite/gdb.threads/linux-dp.exp.
ERROR: can't array set "seen": variable isn't array
    while executing
"array set seen {}"
    (file "../../../archer/gdb/testsuite/gdb.threads/linux-dp.exp" line 342)
    invoked from within
"source ../../../archer/gdb/testsuite/gdb.threads/linux-dp.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source ../../../archer/gdb/testsuite/gdb.threads/linux-dp.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""


This fixes the problem by unsetting 'seen' before the 'array set'.
There's no reason to do things in the current order, the unset removes
the "array-ness".

It would be nice if dejagnu made a new interpreter for each .exp file,
so that variable name clashes couldn't happen...

Tom

2012-04-25  Tom Tromey  <tromey@redhat.com>

	* gdb.threads/linux-dp.exp: Unset 'seen' before 'array set'.

Index: gdb.threads/linux-dp.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/linux-dp.exp,v
retrieving revision 1.30
diff -u -r1.30 linux-dp.exp
--- gdb.threads/linux-dp.exp	16 Jan 2012 16:21:53 -0000	1.30
+++ gdb.threads/linux-dp.exp	25 Apr 2012 13:50:51 -0000
@@ -339,8 +339,8 @@
 }
 
 set any_interesting 0
+catch {unset seen}
 array set seen {}
-unset seen
 for {set i 1} {$i <= $nthreads} {incr i} {
     if [check_philosopher_stack $i seen] {
 	set any_interesting 1

Re: FYI: fixlet for linux-dp.exp

[Pedro Alves]

On 04/25/2012 02:53 PM, Tom Tromey wrote:

> It would be nice if dejagnu made a new interpreter for each .exp file,
> so that variable name clashes couldn't happen...


I assume this would mean use "interp create".  It's even on dejagnu's TODO file:

Last updated $Date: 2004/02/08 14:02:07 $

  Bigger items
  ============
  ...
  * Use a throw-away slave interpreter for running each test case.

I think the trouble would be globals that _are_ supposed to be persistent
across tests, like e.g., "portnum", or whatever other globals board
files can come up with.  We'd need some common way to make
those "master interp" owned variables (through aliases or env vars?).
Alternatively, we could save/restore globals, but there's no globals
standard naming scheme in place to make that remotely sane.

-- 
Pedro Alves

Re: FYI: fixlet for linux-dp.exp

[Joel Brobecker]

>   Bigger items
>   ============
>   ...
>   * Use a throw-away slave interpreter for running each test case.
> 
> I think the trouble would be globals that _are_ supposed to be persistent
> across tests, like e.g., "portnum", or whatever other globals board
> files can come up with.  We'd need some common way to make
> those "master interp" owned variables (through aliases or env vars?).
> Alternatively, we could save/restore globals, but there's no globals
> standard naming scheme in place to make that remotely sane.

In AdaCore's testsuite, we addressed this sort of problem by
assigning IDs to each slave run. For instance, I routinely run
our testsuite at -j24 on my quad-core laptop, and the main loop
creates a pool of 24 slave processes, and each have a numeric ID
going from 1 to 24. When one is done with a testcase, a new one
with the same ID is started again. For something like "portnum",
I'm guessing that it would be easy to calculate it instead of
treating as a persistent global.

It also happens that we have a way for the main loop to transmit
data from the main loop down to the slave (based on JSON), but
we do not allow the slave to change globals back in the main loop.
The only data that we read back are the testcase results.

-- 
Joel

Re: FYI: fixlet for linux-dp.exp

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I assume this would mean use "interp create".  It's even on
Pedro> dejagnu's TODO file:

Yeah.  Or possibly just with "namespace", but I think that may be harder.

Pedro> I think the trouble would be globals that _are_ supposed to be persistent
Pedro> across tests, like e.g., "portnum", or whatever other globals board
Pedro> files can come up with.  We'd need some common way to make
Pedro> those "master interp" owned variables (through aliases or env vars?).
Pedro> Alternatively, we could save/restore globals, but there's no globals
Pedro> standard naming scheme in place to make that remotely sane.

Yes, for "advertised" globals we'd have to make aliases and arrange for
them to be shared.

But, the idea is to avoid odd problems like the one I hit, where test
ordering can cause errors due to minor clashes from the choice of
local-to-the-.exp variable names.

In the end it is probably simpler to just fix our tests when random
issues crop up, than it is to try to fix dejagnu.  Plus maybe we could
use namespaces more in our own tests or something like that.

Tom