From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69289 invoked by alias); 30 Jul 2018 21:48:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 69111 invoked by uid 89); 30 Jul 2018 21:48:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=feeling, guilty, H*F:D*be, our X-HELO: mailsec111.isp.belgacom.be Received: from mailsec111.isp.belgacom.be (HELO mailsec111.isp.belgacom.be) (195.238.20.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Jul 2018 21:48:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1532987294; x=1564523294; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=zRj8CiPU2wrkYWpCK46fB/6LJMfiIjBtYvVUZtGcY3Q=; b=PbG+HkF9TgQBKRw3FkgIgg+MtGGXbEu8CLpVYEjcgtNtJgKgNJXc1hVK 3co0K1q7lKRt6R3lV0qCnDMV4QSmOg==; Received: from unknown (HELO md) ([109.134.172.14]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 30 Jul 2018 23:48:11 +0200 Message-ID: <1532987291.1467.19.camel@skynet.be> Subject: Re: [RFA_v4 1/8] Add helper functions parse_flags and parse_flags_qcs From: Philippe Waroquiers To: Joel Brobecker Cc: gdb-patches@sourceware.org Date: Mon, 30 Jul 2018 21:48:00 -0000 In-Reply-To: <20180730201556.GA19069@adacore.com> References: <20180710213926.32240-1-philippe.waroquiers@skynet.be> <20180710213926.32240-2-philippe.waroquiers@skynet.be> <20180730201556.GA19069@adacore.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00799.txt.bz2 On Mon, 2018-07-30 at 13:15 -0700, Joel Brobecker wrote: > > gdb/ChangeLog > > 2018-07-09 Philippe Waroquiers > > > > * 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) (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 :)