[Lldb-commits] [Bug 12232] New: assert(ivar_decl != NULL) triggers in SymbolFileDWARF::ParseChildMembers for C++
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Sat Mar 10 11:25:08 PST 2012
http://llvm.org/bugs/show_bug.cgi?id=12232
Bug #: 12232
Summary: assert(ivar_decl != NULL) triggers in
SymbolFileDWARF::ParseChildMembers for C++
Product: lldb
Version: unspecified
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Keywords: crash-on-invalid
Severity: normal
Priority: P
Component: All Bugs
AssignedTo: lldb-commits at cs.uiuc.edu
ReportedBy: abigagli at gmail.com
Classification: Unclassified
On OSX 10.7.3, LLDB built from trunk at 152495.
I have a "pure" C++ program (i.e. neither Objective-C nor Objective-C++) built
with fsf-gcc-4.6.2 in std=c++0x mode.
While debugging it with LLDB, i frequently hit the
assert (ivar_decl != NULL);
at line 1645 in SymbolFileDWARF::ParseChildMembers.
The code around is as follows:
if (prop_name != NULL)
{
clang::ObjCIvarDecl *ivar_decl =
clang::dyn_cast<clang::ObjCIvarDecl>(field_decl);
assert (ivar_decl != NULL);
GetClangASTContext().AddObjCClassProperty (class_clang_type,
prop_name,
0,
ivar_decl,
prop_setter_name,
prop_getter_name,
prop_attributes);
}
I verified (debugging LLDB itself) that prop_name has indeed a value.
But of course the dyn_cast to clang::ObjCIvarDecl fails (there is no
ObjCIvarDecl in sight here) resulting in ivar_decl being NULL and hence the
assert kicks in.
I'm not good enough to understand why this code gets under the impression
there's some ObjC properties, and at the moment I've applied the following
patch to be able to keep debugging:
Index: SymbolFileDWARF.cpp
===================================================================
--- SymbolFileDWARF.cpp (revision 152495)
+++ SymbolFileDWARF.cpp (working copy)
@@ -1642,9 +1642,9 @@
{
clang::ObjCIvarDecl *ivar_decl =
clang::dyn_cast<clang::ObjCIvarDecl>(field_decl);
- assert (ivar_decl != NULL);
+ //assert (ivar_decl != NULL);
-
+ if (ivar_decl)
GetClangASTContext().AddObjCClassProperty(
class_clang_type,
prop_name,
0,
That seems to be working for now (I'm able to continue stepping through over
the instructions that were previously asserting), but I'd rather prefer this to
be checked and possibly solved in a more substantial way.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the lldb-commits
mailing list