You can check this yourself by searching for "wxClientDataContainer" in an command line LLDB session that has your debug symbols loaded for codelight:
% lldb /path/to/codelight (lldb) image lookup --type wxClientDataContainer See if you see any complete definitions that are printed out. If so, then solution #1 will probably get around this issue for the moment. But we should still not crash even if we do look for a complete "wxClientDataContainer" definition and don't find one (also part of the fix for solution #1). Greg On Apr 8, 2014, at 2:16 PM, Eran Ifrah <[email protected]> wrote: > > > > On Wed, Apr 9, 2014 at 12:11 AM, Greg Clayton <[email protected]> wrote: > This is a serious problem with the debug info that GCC and Clang recently > started to emit to try and save space by omitting important debug info. > > The problem is: > > class A : public B > { > } > > The debug info for "A" is complete, but since no one used stuff from class > "B" they decided to just forward declare "B". Why is this a problem? Because > we are trying to reconstruct a class definition of "A" using incomplete > information. > > There are two things that can fix this: > 1 - Modify the DWARF parser to look for a complete version of "B" elsewhere > in the current executable's debug info (but there might not be one). > 2 - Change flags to GCC to have it not elide this debug info (don't know what > these flags would be, you will need to find out if there is such a flag). > 3 - Just start and complete the definition for "B" and pretend it is a class > that contains nothing > > Solution #1 is might alleviate some of the problems, but often will result in > a failure when there is no complete definition of "B". > > Solution #2 is the best solution, but this doesn't mean that people won't run > into this crasher when debugging random code. > > Solution #3 is dangerous because you might have foo.cpp whose debug info has > complete definitions for A and B, and bar.cpp that has a complete definition > for A but not for B. Then you write and expression that uses an instance of > "A" from foo.cpp and uses it with an instance of "A" from bar.cpp and the > expression parser will now complain that is has two competing definitions for > class "A" that don't match. > > Solution #1 should probably be tried first. If you can send me the executable > you were debugging with debug info inside it, I can look and see if solution > #1 will fix your current problem. We should avoid crashing, that is for sure. > > This might be a slight problem since I was trying to debug codelite. > With debug symbols it can go up to 200MB and it consists of way too many > shared libraries > Let me first to try and narrowing it to something minimalistic > > > Greg > > On Apr 8, 2014, at 1:49 PM, Eran Ifrah <[email protected]> wrote: > > > Hi, > > > > While debugging a real world application (codelite) I placed a breakpoint > > in the 'OnAbout' function > > attempting to view any of the local variables resulted in crash, see below: > > > > Process 24146 stopped > > * thread #1: tid = 24146, 0x00000000006667f6 > > codelite`clMainFrame::OnAbout(this=0x000000000215f5c0, > > (null)=0x00007fffa6fd2640) + 66 at frame.cpp:1794, name = 'codelite', stop > > reason = step over > > frame #0: 0x00000000006667f6 > > codelite`clMainFrame::OnAbout(this=0x000000000215f5c0, > > (null)=0x00007fffa6fd2640) + 66 at frame.cpp:1794 > > 1791 wxString mainTitle; > > 1792 mainTitle = CODELITE_VERSION_STR; > > 1793 > > -> 1794 AboutDlg dlg(this, mainTitle); > > 1795 dlg.SetInfo(mainTitle); > > 1796 dlg.ShowModal(); > > 1797 } > > (lldb) p dlg > > error: libwx_gtk2u_unofficial_core-3.0.so.0 DWARF DIE at 0x030ac4cc for > > class 'wxSizer' has a base class 'wxClientDataContainer' that is a forward > > declaration, not a complete definition. > > Please file a bug against the compiler and include the preprocessed output > > for > > /home/david/devel/packages/wx/3.0-2/wxwidgets3.0-3.0.0/objs_gtk_sh/../src/common/sizer.cpp > > Segmentation fault > > > > From the segfault message, I understand that this is a bug with gcc > > Still, is there a way to suppress this error by telling lldb to silently > > ignore this? ( I prefer it to display nothing instead of crashing and > > taking down codelite with it ) > > > > Thanks > > > > -- > > Eran Ifrah > > Author of codelite, a cross platform open source C/C++ IDE: > > http://www.codelite.org > > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org > > _______________________________________________ > > lldb-dev mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > -- > Eran Ifrah > Author of codelite, a cross platform open source C/C++ IDE: > http://www.codelite.org > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
