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: [PATCH] fix for info thread on bad input


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


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