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: [RFC] info threads takes an argument


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.

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

I am not seeing these failures, even on the trunk. Would you guys please email me your gdb.log files for this test?

Thanks,
Michael


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