Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs
Date: Mon, 30 Jul 2018 21:48:00 -0000	[thread overview]
Message-ID: <1532987291.1467.19.camel@skynet.be> (raw)
In-Reply-To: <20180730201556.GA19069@adacore.com>

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 :)


  parent reply	other threads:[~2018-07-30 21:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-10 21:39 [RFA_v4 0/8] Implement 'frame apply COMMAND', enhance 'thread apply COMMAND' Philippe Waroquiers
2018-07-10 21:39 ` [RFA_v4 2/8] Implement frame apply [all | COUNT | -COUNT | level LEVEL... ] [FLAG]... COMMAND Philippe Waroquiers
2018-07-14  1:49   ` Simon Marchi
2018-07-14 12:37     ` Tom Tromey
2018-07-10 21:39 ` [RFA_v4 7/8] Modify gdb.threads/pthreads.exp to test FLAG qcs arguments for thread apply. Also, add prefixes to make some non unique tests unique Philippe Waroquiers
2018-07-10 21:39 ` [RFA_v4 3/8] Add [FLAG]... arguments to 'thread apply' Philippe Waroquiers
2018-07-10 21:39 ` [RFA_v4 8/8] Add a self-test for cli-utils.c Philippe Waroquiers
2018-07-10 21:39 ` [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs Philippe Waroquiers
2018-07-30 20:16   ` Joel Brobecker
2018-07-30 21:10     ` Tom Tromey
2018-07-31 13:52       ` Joel Brobecker
2018-07-31 15:41         ` Tom Tromey
2018-07-31 21:13           ` Philippe Waroquiers
2018-08-01  4:04             ` Tom Tromey
2018-08-01  4:34               ` Tom Tromey
2018-07-30 21:48     ` Philippe Waroquiers [this message]
2018-07-10 21:39 ` [RFA_v4 4/8] Documents the new commands 'frame apply', faas, taas, tfaas Philippe Waroquiers
2018-07-11  3:06   ` Eli Zaretskii
2018-07-11  5:57     ` Philippe Waroquiers
2018-07-10 21:39 ` [RFA_v4 6/8] Add a test for 'frame apply' Philippe Waroquiers
2018-07-10 21:39 ` [RFA_v4 5/8] Announce the user visible changes for frame/thread apply in NEWS Philippe Waroquiers
2018-07-11 10:58 ` [RFA_v4 0/8] Implement 'frame apply COMMAND', enhance 'thread apply COMMAND' Pedro Alves
2018-07-12 21:12   ` Philippe Waroquiers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1532987291.1467.19.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox