From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19643 invoked by alias); 15 Jun 2009 20:01:34 -0000 Received: (qmail 19525 invoked by uid 22791); 15 Jun 2009 20:01:32 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Jun 2009 20:01:23 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n5FK1LxG013282 for ; Mon, 15 Jun 2009 16:01:21 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5FK1KWq003616 for ; Mon, 15 Jun 2009 16:01:20 -0400 Received: from opsy.redhat.com (vpn-13-64.rdu.redhat.com [10.11.13.64]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5FK1Ksm006309; Mon, 15 Jun 2009 16:01:20 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 714C83784BE; Mon, 15 Jun 2009 14:01:19 -0600 (MDT) To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Robustifying pretty-printers References: <200906131411.34204.vladimir@codesourcery.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Mon, 15 Jun 2009 20:01:00 -0000 In-Reply-To: <200906131411.34204.vladimir@codesourcery.com> (Vladimir Prus's message of "Sat\, 13 Jun 2009 14\:11\:33 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00163.txt.bz2 >>>>> "Vladimir" == Vladimir Prus writes: Vladimir> While playing with pretty-printers and KDevelop, I've got GDB Vladimir> to "hang", with the below backtrace: Yeah :( Vladimir> Now, what are the best strategies for fix this (assuming GCC Vladimir> won't be fixed for 10 years to come)? It will be fixed, but that won't matter, because users will still smash the stack. Vladimir> Alternatively, we might need to revive the code to limit the Vladimir> number of children to fetch, and use some reasonable limit, Vladimir> like 10. Comments? With the current libstdc++ printers I am sure you will be able to come up with any number of weird problems here. A few thoughts: * In the case of iterating over a container, the CLI code here already does the right thing -- it iterates over the children and respects "set print elements". If the python code returns an iterable object (i.e., it doesn't immediately fetch all the children), then I think the result should be fairly sensible. (Most libstdc++ printers do this, but I haven't checked them all recently.) So, one idea is to do as you suggest: resurrect the child-limiting code for MI. This is necessary but not sufficient, because the previous patches did not make varobj fetch lazily. This should not be very hard, though. * We can add a new Value method to detect whether a pointer-valued Value is valid. Then we could weed out some bad cases early in the printers. * I'm not sure what to do about std::string. Here, lazy iteration cannot fix the problem. We could bake "print elements" awareness into the printer itself, but this is unsatisfactory since it can yield the "wrong" display to the user in some cases (string printing is very weird IMNSHO). Maybe 3 times this limit or something like that would work well enough in most situations. Or maybe we can just ignore the weird corner cases. It would be nice if there were a way to make this magically work for all printers without the printer authors needing to do anything special. I don't see how that could be done, though. Let me know what you think. I'm planning to fix all the known printer problems shortly. Tom