This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug mi/12555] Hangup in MI commands if python StdStringPrinter usedon uninitialized std::string
- From: "andre.poenitz at nokia dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 18 Apr 2011 11:40:42 +0000
- Subject: [Bug mi/12555] Hangup in MI commands if python StdStringPrinter usedon uninitialized std::string
- Auto-submitted: auto-generated
- References: <bug-12555-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12555
--- Comment #6 from Andre Poenitz <andre.poenitz at nokia dot com> 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.