This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] fix for info thread on bad input
- From: Pedro Alves <palves at redhat dot com>
- To: Muhammad Waqas <mwaqas at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 02 Sep 2013 20:31:14 +0100
- Subject: Re: [PATCH] fix for info thread on bad input
- Authentication-results: sourceware.org; auth=none
- References: <1377844357-19923-1-git-send-email-mwaqas at codesourcery dot com>
On 08/30/2013 07:32 AM, Muhammad Waqas wrote:
> Hi
>
> While I was doing some work on threads. I noticed a bug in
> info thread command on bad input.
Thanks.
>
> Let we have 2 threads.
>
> (gdb) info thread
> Id Target Id Frame
> * 2 Thread 0x7ffff77fd700 (LWP 4169) "a.out" start (arg=0x0) at 11568.c:5
> 1 Thread 0x7ffff7fdc700 (LWP 4166) "a.out" 0x00007ffff7bc6148 in pthread_join ()
> from /lib/x86_64-linux-gnu/libpthread.so.0
> (gdb) info thread 1 2 foo
> Id Target Id Frame
> * 2 Thread 0x7ffff77fd700 (LWP 4169) "a.out" start (arg=0x0) at 11568.c:5
> 1 Thread 0x7ffff7fdc700 (LWP 4166) "a.out" 0x00007ffff7bc6148 in pthread_join ()
> from /lib/x86_64-linux-gnu/libpthread.so.0
>
> So gdb not giving error "Args must be numbers or $ variables.".
> I fixed this iterating over all requested threads.
> Please find below patch for it.
So this looks like all uses of number_is_in_list will have
the same problem, no? That calls for a more general solution.
If going this direction, this new code should be really a new
a validation function in cli-utils.c, that is then called from
threads.c and wherever else we're using number_is_in_list similarly.
(The validation function can look like your patch, but it can
be made a little smarter, in that it can poke at state->end_value,
state->last_retval, etc. to skip most of the 30k calls to
get_number_or_range in e.g., a 1-30000 range. number_is_in_list
itself could have the same optimization, so this is not a requirement.)
(Alternatively, we could flip the loops around, by looping over numbers
first, instead of looping over threads and checking whether they were
listed, though that'd change the output of "info threads 1 2" (it'd
print thread 1, then thread 2), which I guess isn't desirable, though
I've pondered before making that an option, so the user can precisely
control the order of threads printed.)
--
Pedro Alves