From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30757 invoked by alias); 10 Dec 2004 20:00:59 -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 30402 invoked from network); 10 Dec 2004 20:00:50 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 10 Dec 2004 20:00:50 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id PAA11438 for ; Fri, 10 Dec 2004 15:21:31 -0500 Received: from [10.12.1.181] (dhcpa181 [10.12.1.181]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id PAA07626 for ; Fri, 10 Dec 2004 15:00:50 -0500 Message-ID: <41BA0117.40407@qnx.com> Date: Fri, 10 Dec 2004 20:00:00 -0000 From: Kris Warkentin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: gdb crash when printing C++ class Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00074.txt.bz2 Some background: I'm using Intel's icc compiler with Dinkum C++ headers. I have a feeling that there is something wrong with the way the debug info is being generated but I want to understand the issue a bit better before I send it off to them. In gnuv3_baseclass_offset there is a section of code described by this comment: /* We're now looking for the cur_base_offset'th entry (negative index) in the vcall_and_vbase_offsets array. We used to cast the object to its TYPE_VPTR_BASETYPE, and reference the vtable as TYPE_VPTR_FIELDNO; however, that cast can not be done without calling baseclass_offset again if the TYPE_VPTR_BASETYPE is a virtual base class, as described in the v3 C++ ABI Section 2.4.I.2.b. Fortunately the ABI guarantees that the vtable pointer will be located at the beginning of the object, so we can bypass the casting. Verify that the TYPE_VPTR_FIELDNO is in fact at the start of whichever baseclass it resides in, as a sanity measure - iff we have debugging information for that baseclass. */ vbasetype = TYPE_VPTR_BASETYPE (type); if (TYPE_VPTR_FIELDNO (vbasetype) < 0) fill_in_vptr_fieldno (vbasetype); When I try to print an ostream variable, gdb crashes because vbasetype is dereferenced when type->main_type->vptr_basetype is null. In fact, TYPE_VPTR_FIELDNO(type) is -1 so as one of my tests, I tried calling fill_in_vptr_fieldno(type) but that didn't fill it in. As a workaround to prevent the crash, I just return -1 if TYPE_VPTR_BASETYPE(type) is null and then I get something like this: 10 ostream foo; (gdb) p foo $1 = { >> = , members of std::ostream: _vptr.basic_ostream > = void } Using gcc with very similar headers, I get much nicer output: 10 ostream foo; (gdb) p foo $6 = { >> = { <> = {}, members of std::basic_ios >: _Mystrbuf = 0x0, _Tiestr = 0x0, _Fillch = 32 ' ' }, members of std::ostream: _vptr.basic_ostream = 0x804f38c } Where was the vptr_basetype set up in the first place? Since type claims to have a baseclass, logically the baseclass pointer shouldn't be void so I'm assuming it just didn't get filled in somewhere. Can anyone give me any hints on how to determine if Intel's debug info is off? cheers, Kris