This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs
On Mon, 2018-07-30 at 13:15 -0700, Joel Brobecker wrote:
> > gdb/ChangeLog
> > 2018-07-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
> >
> > * cli-utils.c (number_or_range_parser::get_number): Only handle
> > numbers or convenience var as numbers.
> > (parse_flags): New function.
> > (parse_flags_qcs): New function.
> > (number_or_range_parser::finished): Ensure parsing end is detected
> > before end of string.
> > * cli-utils.h (parse_flags): New function.
> > (parse_flags_qcs): New function.
> > (number_or_range_parser): Remove m_finished bool.
> > (number_or_range_parser::skip_range): Set m_in_range to false.
>
> For the record, this patch is causing some regressions that look
> related to memory management (in this case, probably reading memory
> that has already been freed). It's not always user-visible, but the
> easiest way I have found to demonstrate the issue is to use valgrind
> with the following example:
As I felt a little bit guilty, I still started to look at it (and then I saw
the mail of Tom telling he already has a fix).
As far as I can see, the underlying problem was already there with the
below reproducer and gdb 8.1, but you just had to do 2 breakpoints and
then use 'command 1 2':
gdb -ex 'break main' -ex 'break main' ./c
GNU gdb (GDB) 8.1
....
Breakpoint 1 at 0x669: file c.c, line 1.
Note: breakpoint 1 also set at pc 0x669.
Breakpoint 2 at 0x669: file c.c, line 1.
(gdb) command 1 2
Type commands for breakpoint(s) 1 2, one per line.
End with a line saying just "end".
>end
==26216== Invalid read of size 1
==26216== at 0x21B424: number_or_range_parser::get_number() (cli-utils.c:167)
==26216== by 0x2B52F7: map_breakpoint_numbers(char const*, gdb::function_view<void (breakpoint*)>) (breakpoint.c:14130)
==26216== by 0x2BEF88: commands_command_1(char const*, int, command_line*) (breakpoint.c:1274)
==26216== by 0x2148E8: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1886)
==26216== by 0x44D8B7: execute_command(char const*, int) (top.c:630)
....
Outside of valgrind, the behaviour is strange,
as gdb 8.1 (and gdb 8.2) ask twice a list of commands :
(gdb) command 1 2
Type commands for breakpoint(s) 1 2, one per line.
End with a line saying just "end".
>end
Type commands for breakpoint(s) 1 2, one per line.
End with a line saying just "end".
>end
(gdb)
As far as I could see, the problem is that when handling a line of input
(provided via a const char* arg), reading some more lines of input will
free the previous line (but which is still being parsed in our case).
Waiting impatiently to see the fix done by Tom.
Philippe, feeling not too guilty anymore :)