In the meanwhile, here is the crash backtrace when it crashe ( the scenario is: gdb is debugging lldb which debugs a debug version of codelite ;) ) http://pastebin.com/PVcZeQFk
HTH On Wed, Apr 9, 2014 at 12:19 AM, Greg Clayton <[email protected]> wrote: > 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 > > -- 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
