Re: [RFC] info threads takes an argument

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 16 Feb 2011 19:26:33 +0100, Michael Snyder wrote:
> Pedro Alves wrote:
> >Anyway, the reason I'm replying is that I noticed a couple
> >of new FAILs in this test, and looking at the log, I noticed
> >another issue:
> 
> Urk.  I did half my work on the 7.2 branch, where it doesn't do this.
> Let me fix it.

I also see the failure:

info threads 2 4 6
  Id   Target Id         Frame 
  2    Thread 0x7ffff759e700 (LWP 24773) "threadname_2" 0x00007ffff7678213 in select () at ../sysdeps/unix/syscall-template.S:82
  Id   Target Id         Frame 
  4    Thread 0x7ffff659c700 (LWP 24775) "threadname_4" 0x00007ffff7678213 in select () at ../sysdeps/unix/syscall-template.S:82
  Id   Target Id         Frame 
  6    Thread 0x7ffff559a700 (LWP 24777) "threadname_6" __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
(gdb) FAIL: gdb.threads/thread-find.exp: info threads 2 4 6

    -re ". 6 .*\"threadname_6.*\" \[\r\n\]*" {
        set see6 1
        exp_continue
    }
    -re ". 5 .*\"threadname_5.*\" \[\r\n\]*" {
        set see5 1
        exp_continue
    }

This is racy, * of the regexp is greedy by default and there can be multiple
threadnames available during a single read/match, one match can swallow
multiple entries.  There should be some \[^\r\n\]* instead of any .* during
such unanchored matching.

One may also rather catch the whole output and regex-match by hand the caught
output afterwards.


Thanks,
Jan