C::B crash (Settings-->Editor)

[Michael]

Hello,

I think that this is an already-know problem, but I would like to know how can I continue to use the: Settings-->Editor.

I had just finished to build C::B by using its project file (C::B rev2156) and I wanted to change something in the Settings-->Editor. C::B crashed and I had to kill the process. When trying to re-opening it, C::B looked ok, but when I tried to open the Settings-->Editor, I got a "Debug report "codeblocks" dialog. It said that a debug report was generated under "/tmp/codeblocks_dbgrpt-10597-20060309T124959". The report is depicted below, but how can I re-use the Settings-->Editor? I continue to get the "Debug report "codeblocks" dialog.

<?xml version="1.0" encoding="utf-8"?>
<report version="1.0" kind="exception">
  <system description="Linux 2.6.12-10-386 i686"/>
  <modules>
    <module path="[heap]" address="080e1000" size="017bc000"/>
    <module path="/SYSV00000000" address="b675f000" size="000c0000"/>
    <module path="/SYSV00000000" address="b7f08000" size="00003000"/>
    <module path="[stack]" address="bfd0f000" size="00016000"/>
  </modules>
  <stack>
    <frame level="2" function="wxStackWalker::Walk(unsigned int)" offset="00000030"/>
    <frame level="3" function="wxDebugReport::AddContext(wxDebugReport::Context)" offset="00000a16"/>
    <frame level="4" function="wxDebugReport::AddAll(wxDebugReport::Context)" offset="00000018"/>
    <frame level="5" function="CodeBlocksApp::OnFatalException()" offset="00000000" file="src/app.cpp" line="490"/>
    <frame level="6" function="wxFatalSignalHandler" offset="00000026"/>
    <frame level="7"/>
    <frame level="8" function="wxStringBase::AllocBeforeWrite(unsigned int)" offset="0000001f"/>
    <frame level="9" function="wxStringBase::AssignCopy(unsigned int, wchar_t const*)" offset="00000060"/>
    <frame level="10" function="wxStringBase::operator=(wchar_t const*)" offset="00000038"/>
    <frame level="11" function="wxString::operator=(wchar_t const*)" offset="00000022" file="/usr/include/wx-2.6/wx/string.h" line="854"/>
    <frame level="12" function="CodeStat::LoadSettings(LanguageDef*)" offset="00000027"/>
    <frame level="13" function="CodeStat::GetConfigurationPanel(wxWindow*)" offset="00000090"/>
    <frame level="14" function="PluginManager::GetConfigurationPanels(int, wxWindow*, ConfigurationPanelsArray&amp;)" offset="00000124"/>
    <frame level="15" function="EditorConfigurationDlg::AddPluginPanels()" offset="000000cb"/>
    <frame level="16" function="EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)" offset="00002276"/>
    <frame level="17" function="EditorManager::Configure()" offset="00000051"/>
    <frame level="18" function="MainFrame::OnSettingsEditor(wxCommandEvent&amp;)" offset="0000002d" file="src/main.cpp" line="2951"/>
    <frame level="19" function="wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&amp;), wxEvent&amp;) const" offset="00000031"/>
    <frame level="20" function="wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&amp;, wxEvtHandler*, wxEvent&amp;)" offset="0000007d"/>
    <frame level="21" function="wxEventHashTable::HandleEvent(wxEvent&amp;, wxEvtHandler*)" offset="00000074"/>
    <frame level="22" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="000000bd"/>
    <frame level="23" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="24" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="25" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="26" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="27" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="28" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="29" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="30" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="31" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="32" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="33" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="34" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="35" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="36" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="37" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="38" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="39" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="40" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="41" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="42" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="43" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="44" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="45" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000063"/>
    <frame level="46"/>
    <frame level="47" function="g_cclosure_marshal_VOID__VOID" offset="00000043"/>
    <frame level="48" function="g_closure_invoke" offset="0000011e"/>
    <frame level="49"/>
    <frame level="50" function="g_signal_emit_valist" offset="000006ab"/>
    <frame level="51" function="g_signal_emit" offset="00000029"/>
    <frame level="52" function="gtk_widget_activate" offset="0000008a"/>
    <frame level="53" function="gtk_menu_shell_activate_item" offset="000000d0"/>
    <frame level="54"/>
    <frame level="55"/>
    <frame level="56" function="_gtk_marshal_BOOLEAN__BOXED" offset="00000058"/>
    <frame level="57"/>
    <frame level="58" function="g_closure_invoke" offset="0000011e"/>
    <frame level="59"/>
    <frame level="60" function="g_signal_emit_valist" offset="0000041e"/>
    <frame level="61" function="g_signal_emit" offset="00000029"/>
    <frame level="62"/>
    <frame level="63" function="gtk_propagate_event" offset="000000c1"/>
    <frame level="64" function="gtk_main_do_event" offset="00000325"/>
    <frame level="65"/>
    <frame level="66" function="g_main_context_dispatch" offset="000001dc"/>
    <frame level="67"/>
    <frame level="68" function="g_main_loop_run" offset="000001a1"/>
    <frame level="69" function="gtk_main" offset="000000b4"/>
    <frame level="70" function="wxEventLoop::Run()" offset="00000055"/>
    <frame level="71" function="wxAppBase::MainLoop()" offset="0000004c"/>
    <frame level="72" function="wxAppBase::OnRun()" offset="00000021"/>
    <frame level="73" function="CodeBlocksApp::OnRun()" offset="00000000" file="src/app.cpp" line="461"/>
    <frame level="74" function="wxEntry(int&amp;, wchar_t**)" offset="0000005c"/>
    <frame level="75" function="wxEntry(int&amp;, char**)" offset="00000032"/>
    <frame level="76" function="main" offset="00000394" file="src/app.cpp" line="89"/>
  </stack>
</report>

Thank you very much.

Best wishes,
Michael

PS.: I use ubuntu 5.10

[MortenMacFly]

"/tmp/codeblocks_dbgrpt-10597-20060309T124959" [...]

Did you run the C::B version of the output folder? If so, could you please try again using the "debug" version from the devel folder? Thus the offset addresses in the crash report should be de-referenced to the actual lines in the sources.
With regards, Morten.

[Michael]

Hello,

Thanks for your answer .

I use already the devel C::B. I have done a link of the run.sh, which is located under /home/michael/devel/trunk/src/devel/run.sh

Best wishes,
Michael

[mandrav]

AFAIK, the crash is caused by the codestat plugin.
I haven't investigated why though...

[Michael]

AFAIK, the crash is caused by the codestat plugin.
I haven't investigated why though...

Thank you very much for your answer . I always keep each plugin active and never de-selected one (on windows at least). I will try to remove Codestat plugin.

I have tried to re-start the computer, but I continue to get the Debug report dialog and then C:.B quits. So, I think that I have to delete the devel repository and make a full re-build with the C::B I have built using make.

Best wishes,
Michael

[Michael]

Yes, it seems it was the codestat plugin. Strange, because since I use C::B on ubuntu 5.10, I never got that crush. But since I got it, C::B crushes at each time, I try to change the Editor's settings. Now that I have removed it it works well again.

Best wishes,
Michael

[Ceniza]

Codestat? So why am I having the same problem with no contribs?

If I open Code::Blocks (without opening anything) and go to Settings -> Editor, it shows the dialog without problems, but if I open a project and try the same it just dies (but no ugly crash). If I open the project, close it and try it, it also dies. A lovely 0% CPU usage death.

I just tried disabling CodeCompletion and it works fine.

In fact I've found that plugin really useless under Linux. I just cannot get it to work.

I loaded a project, tried Reparse now and it's all I get:

[10:21:32.842]: Add project Client in parsing queue
[10:21:38.808]: Add project Client in parsing queue

[takeshimiya]

I just tried disabling CodeCompletion and it works fine.

Same here.

In fact I've found that plugin really useless under Linux. I just cannot get it to work.

Indeed, I think we need to put a big warning on linux, because the CodeCompletion and wxSmith plugins are really unuseable there at the moment.

[Michael]

Codestat? So why am I having the same problem with no contribs?

I have not tried a lot, but what I have remarked is that when I have installed C::B for the first time and enabled all the plugins, C::B worked fine. Then when I tried to open the Settings-->Editor, it crashed and continue to crash even if no project were loaded. I misundertood Yannis and disabled code completion. C::B continued to crash. Then I disabled codestat and re-enabled code completition and...C::B worked. Anyway, there must be some bugs somewhere that prevent C::B under Linux to work fine.

Best wishes,
Michael

[aarti_pl]

I got the same bug from quite a long time. It drives me crazy because before I couldn't even compile CB from source using Makefiles. Now it compiles, but it crashes when I try to open almost any dialog which is defined in resources (not only Settings-->Editor).

My Config: Ubuntu Breezy; Codeblocks svn compiled with Makefile.

BR
Aarti_pl

[mandrav]

I got the same bug from quite a long time. It drives me crazy because before I couldn't even compile CB from source using Makefiles. Now it compiles, but it crashes when I try to open almost any dialog which is defined in resources (not only Settings-->Editor).

My Config: Ubuntu Breezy; Codeblocks svn compiled with Makefile.

BR
Aarti_pl

A forum search would have helped you from going crazy...


make clean-zipfiles
make
sudo make install

[aarti_pl]

Probably I will have to get mad

I applied your hint and it changed nothing at all. From settings only works: Editor and Global variables.
Dialogs which doesn't work: Settings-->Environment, Settings-->Compiler and Debugger, Plugins-->Manage Plugins.
When I choose one of these dialogs I get: Error in resource - there is no handler for wxCheckList.

PS1. I recompiled the whole project to make sure that everything is ok. It also doesn't help.
PS2. I can't attach zipped logs because "upload folder is full".

BR
Aarti_pl

[Michael]

Hello,

That very strange, because I have had no problems building C::B and contr.plugins both by make and by using the project file(s). You can try to fully unistall C::B and then trying to re-install it by following the wiki instructions. Anyway, you do not need to build wxWidgets, you can use the pre-installed Ubuntu package (do not forget wx-common package .

You can also give a try of a .deb package (look at my signature) and see if it works for you.

Best wishes,
Michael

[Michael]

Hello,

Following Pecan's suggestion (and to avoid to hijack another topic), I have tried to get more info on my Settings-->Editor crash with codestats plugin (C::B rev2317). Here is the gdb output:

(gdb) run
Starting program: /home/michael/devel/trunk/src/devel/codeblocks
[Thread debugging using libthread_db enabled]
[New Thread -1228880192 (LWP 13442)]

(process:13442): Gdk-WARNING **: locale not supported by Xlib

(process:13442): Gdk-WARNING **: cannot set locale modifiers
[New Thread -1236251728 (LWP 13653)]
[New Thread -1249666128 (LWP 13669)]
[New Thread -1259459664 (LWP 13670)]
[Thread -1259459664 (zombie) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1228880192 (LWP 13442)]
0xb7a05349 in wxStringBase::AllocBeforeWrite ()
   from /usr/lib/libwx_baseu-2.6.so.0
(gdb)

It seems a problem of zombie thread. I have done some tests without codestats plugin, and there still are zombie threads. So, it is probably not the cause of the crash or not directly.

[EDIT]: I have remarked that only the Editor menu has zombie threads. When opening the other Settings menu, no additional thread(s) is created, but when opening Editor (withour or with codestats plugin), two new threads are created and relatively fast, the third is exited and marked as zombie. When closing the Editor menu (without codestats plugin) the second thread is closed and marked as zombie, then another thread is created, exited and marked as zombie.

May be this fact could make problems with codestats plugins and generate the SIGSEGV. 

Best wishes,
Michael

[Pecan]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1228880192 (LWP 13442)]
0xb7a05349 in wxStringBase::AllocBeforeWrite ()
   from /usr/lib/libwx_baseu-2.6.so.0
(gdb)

Michael,

Could you do that again. Then when the "(gdb)" prompt
occurs after the SIGSEGV could you issue a backtrace
command. "bt" so we can see who is entering the
AllocBeforeWrite() segfaulted routine. You may have
to issue a number of "bt"s to see the *cause* of the error.

thanks
pecan