From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3666 invoked by alias); 2 Dec 2011 16:51:01 -0000 Received: (qmail 3653 invoked by uid 22791); 2 Dec 2011 16:51:00 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_SM X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Dec 2011 16:50:41 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB2Goe5h020652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2011 11:50:40 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pB2God9n030168; Fri, 2 Dec 2011 11:50:40 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id pB2GocfV018385; Fri, 2 Dec 2011 11:50:38 -0500 From: Tom Tromey To: asmwarrior Cc: gdb-patches@sourceware.org Subject: Re: [patch] avoid the crash of gdb+pretty printer on initialized local variables References: <4ED379D8.4060808@gmail.com> <4ED8534D.2050100@gmail.com> Date: Fri, 02 Dec 2011 16:51:00 -0000 In-Reply-To: <4ED8534D.2050100@gmail.com> (asmwarrior@gmail.com's message of "Fri, 02 Dec 2011 12:25:49 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2011-12/txt/msg00044.txt.bz2 >>>>> ">" == ext asmwarrior writes: >> When debugger with python pretty printer, I sometimes get the gdb crash >> when I try to show the value of uninitialized local variables. gdb should not crash. Is this that mingw-builds-only problem that keeps popping up? I forget, something to do with not using the right gcc flag? >> The patch is just a work-around/hack to handle this problem. >> I just first check if the symbol is a local variable, and then check the >> current line SAL is smaller than the variable's declaration line. If >> true, which means this local variable is OK to show, if not, than I just >> skip it. This is not ok. First, due to optimization, lines can be smeared around, leading to the wrong result here. Second, a variable can be trashed for many reasons, like other bugs in the code. In this second case it is still unacceptable for gdb to crash. In theory the existing code will detect memory access errors and cause printing to stop early. If you have a case where this doesn't work properly, make a reproducible test case. >> void fun() >> { >> wxString *psty = (wxString*) NULL; >> wxString wxStr(L"wxString"); >> wxStr += L" Value"; >> std::string stdStr("std::string"); >> stdStr.append(" value"); >> std::map m; >> m[0] = "000"; >> m[1] = "111"; //break point here, we stop here This kind of thing is generally not very reproducible. It relies on compiler differences, libraries, runtime differences. Something that is plain C and just writes bad values directly would be better. >> If you try to run "print v", or "info locals", then gdb will crash (I'm >> using gdb cvs build under WindowsXP, mingw, python 2.7) >> I believe that this patch will not be applied, because it is just a >> hack, right? I think it is actively wrong in some cases. >> Basically, gdb should alive with out any crash in any condition, but >> sometimes, I think a workaround is also necessary. I have see that in >> QTcreator, when they want to show the contents of a stl container, it do >> many sanity check. like: >> The length of the std::vector should be positive, and it's size should >> be limited. >> Also many other sanity checks Adding a sanity check to the vector printer would probably be ok. That is maintained in libstdc++. Checking the size is probably not ok. gdb lazily fetch sub-objects; and respects length limits like "set print elements" or the MI equivalent for dynamic varobjs. Having the printer check that the length is "short enough" is generally wrong for this reason. Tom