From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102369 invoked by alias); 2 May 2016 11:50:09 -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 102346 invoked by uid 89); 2 May 2016 11:50:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Luckily, Hx-languages-length:1235 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 02 May 2016 11:50:07 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B974581105; Mon, 2 May 2016 11:50:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u42Bo5JB003896; Mon, 2 May 2016 07:50:05 -0400 Subject: Re: Off-by-one error in windows-nat.c causes abort at startup To: Eli Zaretskii , gdb-patches@sourceware.org References: <83bn4rpd6m.fsf@gnu.org> From: Pedro Alves Message-ID: <62c5fd08-c7b5-37e2-e364-381ae8377c03@redhat.com> Date: Mon, 02 May 2016 11:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <83bn4rpd6m.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00005.txt.bz2 On 04/30/2016 12:07 PM, Eli Zaretskii wrote: > Luckily, I still had GDB 7.5, which did work. Using it, I found the > off-by-one gotcha below (".gdbinit" is one character longer than > "gdb.ini"). I guess no one tested this feature when we switched from > using snprintf to xsnprintf... Sounds like gdb would corrupt memory before we switched to xsnprintf then. I'd say the problem is that the feature was added without a corresponding test case. > OK to commit (with a suitable ChangeLog entry, of course)? Sure. > > --- gdb/windows-nat.c~ 2016-02-10 05:19:39.000000000 +0200 > +++ gdb/windows-nat.c 2016-04-30 11:57:08.500000000 +0300 > @@ -2711,9 +2711,9 @@ _initialize_check_for_gdb_ini (void) > if (access (oldini, 0) == 0) > { > int len = strlen (oldini); > - char *newini = (char *) alloca (len + 1); > + char *newini = (char *) alloca (len + 2); > > - xsnprintf (newini, len + 1, "%.*s.gdbinit", > + xsnprintf (newini, len + 2, "%.*s.gdbinit", > (int) (len - (sizeof ("gdb.ini") - 1)), oldini); > warning (_("obsolete '%s' found. Rename to '%s'."), oldini, newini); (I suspect this whole function could be rewritten in a clearer form...) Thanks, Pedro Alves