From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28887 invoked by alias); 18 Apr 2011 11:41:30 -0000 Received: (qmail 28859 invoked by uid 22791); 18 Apr 2011 11:41:29 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Apr 2011 11:40:43 +0000 From: "andre.poenitz at nokia dot com" To: gdb-prs@sourceware.org Subject: [Bug mi/12555] Hangup in MI commands if python StdStringPrinter used on uninitialized std::string X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: mi X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andre.poenitz at nokia dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 7.4 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 18 Apr 2011 11:41:00 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2011-q2/txt/msg00197.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12555 --- Comment #6 from Andre Poenitz 2011-04-18 11:34:44 UTC --- I still think having a default limit that leave gdb itself (and a frontend using it) in a usable state would make sense. Limiting the size of dumped data to something that finishes dumping in acceptable time (less than a few seconds in total, given the uncertain number of items to display a single display should be well under a second) seems to be a good first approximation at least as long as the data dumping is not interruptible (see 12615). Anyway, if you think the frontend should be required to use --limit=100, so be it. To the second issue: I don't think the assumption that data display can be sensibly steered by keeping track of entering and leaving stack frames or block scopes holds true. Both debugging itself and background activities might (and typically do) result in changed displays. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.