From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27013 invoked by alias); 19 Feb 2005 01:00:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21569 invoked from network); 19 Feb 2005 00:58:27 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 19 Feb 2005 00:58:27 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1D2Ix0-0004rz-Sk; Fri, 18 Feb 2005 16:58:26 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18518-03; Fri, 18 Feb 2005 16:58:26 -0800 (PST) Received: from [192.168.11.101] (helo=tensilica.com) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1D2Ix0-0004rt-GB; Fri, 18 Feb 2005 16:58:26 -0800 Message-ID: <42168F31.3020805@tensilica.com> Date: Sat, 19 Feb 2005 08:33:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: -var-create on invalid expression causes seg. fault Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00121.txt.bz2 Hi, One of our customers reported GDB crashing when an MI variable is created on an invalid address and then referenced. I've debugged to the point of finding the cause, but am not knowledgable enough on the MI variables to know the right way to fix it. I filed a bug report because this needs to get fixed in the latest sources. I'd appreciate any insight so I can fix it in our 5.2.1 based sources. I don't have the time to look deeper, but someone on this list is familiar with this stuff I'm sure. -var-create on an expression that's invalid (eg. "(*1)") creates a variable and retains a ptr in var->value. That gets freed by free_all_values() next command. Later a -var-update or -var-evaluate-expression on that variable dereferences the freed memory, causing a seg. fault. Here's the relevant code snippet from varobj_create(): /* We definitively need to catch errors here. If evaluate_expression succeeds we got the value we wanted. But if it fails, we still go on with a call to evaluate_type() */ if (gdb_evaluate_expression (var->root->exp, &var->value)) { /* no error */ release_value (var->value); if (VALUE_LAZY (var->value)) gdb_value_fetch_lazy (var->value); } else var->value = evaluate_type (var->root->exp); var->type = VALUE_TYPE (var->value); gdb_evaluate_expression() fails, and GDB goes on to call evaluate_type(). I don't think simply clearing var->value is correct. Maybe release_value()? I don't have the time to acquire enough knowledge of GDB varobj. I looked at the GDB 6.3 source and it seems to be the same. Now why would anyone try to evaluate *1? It's some tool that uses MI, one of our customers reported. I'm not clear on why GDB even creates the variable in this case, but it does. GDB should report an error, not crash. Thanks for any insight. --------------- Ross Morley Tensilica, Inc. ross@tensilica.com