From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17514 invoked by alias); 22 Nov 2013 20:35:21 -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 17484 invoked by uid 89); 22 Nov 2013 20:35:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-vc0-f173.google.com Received: from Unknown (HELO mail-vc0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 22 Nov 2013 20:35:20 +0000 Received: by mail-vc0-f173.google.com with SMTP id ia6so1207619vcb.4 for ; Fri, 22 Nov 2013 12:35:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZGCJDiHuVq1j6cmKm7f7Y2LzF2if3cp/H2x90hgVxUo=; b=MCcwXpR4IJf/vX8gLkPXJ4lJ6GCP81SR8+P5D9UTaT6lCili+emGCqQaZtJk6q21p/ k8/W+egBhbommClz2p9kVmYrJPgOh4UnH2iLCg9OQm64W4TEnkfNKJHoKbSzDi3w6Efw Q/tINfWB3pi4oPJ4IfNR1xh2RCb2XBjQ0kBGe8OEAG2TchjaXz4i1sD/uFV7SDQzC8fh MX1ELAYZpFIY8deVORbLP7uWB5e9Be943q26v3XcT7tcsIfFC0znv45hm6kAZ8932bFn JlvjxiDT2iUU8RTX7W6uQRoPOO129+Jh+N6gBQjLpKjPj+Eajr3jdPj9PDisnoW29uG0 qgvA== X-Gm-Message-State: ALoCoQn3ZRgZKlbR5s9JWJ9u1b41FSopNiyPAHYLq7xvNZohZqOhM9X8zc9yVGsirBeb34ITY9EoV+Cr9ybzqXTxbbh0jBN7rqSphDOpvaqG6aSgPp4xzhwUnrCzMD0igKbtIa01gMzHhRUqr1f/yb8TXYrzBNmrWXS1sgpgrNMdIyj4dNT/OdFae33Rf4LYxX9ns9Y4Hzg7mHllFy8JKVNyfzGrJ8PLlg== MIME-Version: 1.0 X-Received: by 10.58.143.17 with SMTP id sa17mr13275207veb.14.1385152511987; Fri, 22 Nov 2013 12:35:11 -0800 (PST) Received: by 10.52.163.52 with HTTP; Fri, 22 Nov 2013 12:35:11 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Nov 2013 20:37:00 -0000 Message-ID: Subject: Re: Fix for pr16196: Honor fetch limit for strings of known size From: Doug Evans To: Sterling Augustine Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00709.txt.bz2 On Fri, Nov 22, 2013 at 12:02 PM, Sterling Augustine wrote: > The enclosed patch fixes 16196, which was revealed when an unitialized > C++ string happened to point to valid memory and had a garbage in the > size field that happened to look very large. GDB then spins a very > long time reading invalid memory. > > The patch fixes this by enforcing the fetch limit (which, in turn, is > set by print elements) even when the size of the string is known. This > makes the function's behavior similar to when the size of the string > isn't know. > > I checked all callers, and it this does not cause any difference in > behavior, and reveals no new problems in the test-suite. > > Thanks > > Sterling > > 2013-11-22 Sterling Augustine > > PR backtrace/16196: > * valprint.c (read_string): Set new variable fetchlen based on > fetchlimit and size. Use it in call to partial_memory_read. > Update comment. LGTM. [There are still other issues, but this patch doesn't have to fix all of them.] I'd change the "backtrace" in backtrace/16196 to something else, not sure what though. "gdb" is always a good fallback. PR gdb/16196.