Jan Kratochvil wrote:
> 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.

You're right, there is an extra .* in there.
Can you please try the attached?