crashes, when loading a workspace and then closing CB

[killerbot]

not attaching the crash report since too big, but it happens to me every time (I did a make clean)

[oBFusCATed]

Hm, killerbot don't post like a newbie. You've missed all the vital information:
- versions, os
- have you tried with disabled all non-important plugins - CC, debugger
- have you debugged it
- exact steps - like when do you close cb, during loading or after loading...

p.s. if this is something that happens only in newer revision, bisecting it will be the easiest way to find the commit that broke things.

[killerbot]

on linux.

Just load for example the code blocks workspace. Once it is loaded, close CB. Yoiu can even wait a long time just to be sure that CC finished parsing , but same result.
Using rev 8394 at the moment.

Done no tests at disabling plug-ins neither debugging. Will see if I can get to that ...

[Jenna]

If I open the C::B workspace and start compiling before CC has finished parsing it hangs in almost every case and has to be killed with kill -9

On fedora 64bit.

[killerbot]

1) crash at destructor of cbAuiNotebook ==> DeletePage => wxObject:IsKindOf

2) crash at destructor of cbAuiNotebook ==> DeletePage => typeinfo for wxProcessEvent

3) crash at destructor of cbAuiNotebook ==> DeletePage => wxObject:IsKindOf
==> in this case I just loaded a simple project
[I had seen that in /tmp there were entries of crashes when I just opened a project and then closed CB, but there was never an xml file present then]

4) crash at destructor of cbAuiNotebook ==> DeletePage => wxObject:IsKindOf
start CB, don't open anything and stop it

or is something playing tricks on me, when launching CB from CB within a debug session ?

[Jenna]

Do you have clean build with pch's removed ?

[killerbot]

I did make clean, didn't do anything more then that, and for the CB with CB build I did rebuild workspace

[oBFusCATed]

I did make clean, didn't do anything more then that, and for the CB with CB build I did rebuild workspace

Now try the full procedure with autotools -> bootstrap, configure, make

[Alpha]

Same crash (I think) on Windows svn 8394.  From the debugger:

Code

#0 05466108	?? () (??:??)
#1 004079F8	InfoPane::~InfoPane(this=0x333eb38, __in_chrg=<optimized out>) (C:\Libraries\CB\src\src\infopane.cpp:61)
#2 00407A95	InfoPane::~InfoPane(this=0x333eb38, __in_chrg=<optimized out>) (C:\Libraries\CB\src\src\infopane.cpp:63)
#3 6CDB994C	wxWindowBase::Destroy() () (C:\Libraries\wxMSW-2.8.12\lib\gcc_dll\wxmsw28u_gcc_cb.dll:??)
#4 004DA770	MainFrame::sm_eventTableEntries () (??:??)
#5 02740AB0	?? () (??:??)
#6 6CC41242	wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&) (C:\Libraries\wxMSW-2.8.12\lib\gcc_dll\wxmsw28u_gcc_cb.dll:??)
#7 0022EA54	?? () (??:??)
#8 ??	?? () (??:??)

And from codeblocks.RPT:

Code

Call stack:
B1CC6D02
6CC80530  C:\Libraries\wxMSW-2.8.12\lib\gcc_dll\wxmsw28u_gcc_cb.dll:6CC80530  _ZNK8wxObject8IsKindOfEP11wxClassInfo
004079F8  C:\Libraries\CB\src\devel\codeblocks.exe:004079F8Dwarf Error: mangled line number section.Dwarf Error: mangled line number section.
00407A95  C:\Libraries\CB\src\devel\codeblocks.exe:00407A95
6CDB994C  C:\Libraries\wxMSW-2.8.12\lib\gcc_dll\wxmsw28u_gcc_cb.dll:6CDB994C  _ZN12wxWindowBase7DestroyEv
6CC41242  C:\Libraries\wxMSW-2.8.12\lib\gcc_dll\wxmsw28u_gcc_cb.dll:6CC41242  _ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_

Reverting rev 8391 seems to resolve the issue.

Code

Index: src/src/main.cpp
===================================================================
--- src/src/main.cpp    (revision 8394)
+++ src/src/main.cpp    (working copy)
@@ -3046,14 +3046,14 @@
     // Hide the window
     Hide();
 
-    Manager::Shutdown(); // Shutdown() is not Free(), Manager is automatically destroyed at exit
-
     if (!Manager::IsBatchBuild())
     {
         m_pInfoPane->Destroy();
         m_pInfoPane = 0L;
     }
 
+    Manager::Shutdown(); // Shutdown() is not Free(), Manager is automatically destroyed at exit
+
     Destroy();
 }

[Jenna]

I feared that this commit is the cause.
Before reverting it, I would like to find if there is a cause for the crash, that can be fixed.

[Jenna]

If I am correct, the cause is, that some of the plugins or the core app do not delete the notebookpages from infopane on close (when app is shutting down), but the associated windows (loggers, lists, whatever) are destroyed.

wxAuiNotebook tries to delete all pages until the notebook is empty and that is what leads to a crash (most likely).

I moved the destroying of infopane after the destroying of managers and plugins, to keep the loggers valid as long as the logmanager might use it.
This was to fix a crash with debug-messages of C::B under wx2.9, that occured after destroying the infopane.
The problem is, that the logger do not write anything into the logwindow, if IsAppShuttingDown() returns true, but the appropriate flag was set after the infopane was destroyed.

A probably better solution would be to explicitely set the m_AppShuttingDown-flag in the manager directly after or even just before sending cbEVT_APP_START_SHUTDOWN.

[Jenna]

This crash, and probably others (related to loggers) should be fixed with svn r8395.
After this commit it seems a long standing issue when shutting down the app is also fixed.
Knock on wood!

[killerbot]

I can confirm that the crash I mentioned is solved by your commit Jens. Well done 

[MortenMacFly]

I can confirm that the crash I mentioned is solved by your commit Jens. Well done  

It also fixes a bug newly introduced: C::B remained invisible in memory on shut-down if not run in batch mode. I was just on my way to track that down...

[dmoore]

If I open the C::B workspace and start compiling before CC has finished parsing it hangs in almost every case and has to be killed with kill -9

On fedora 64bit.

Assume this is separate issue, but got bit by this recently. Any word on a fix?

[Jenna]

If I open the C::B workspace and start compiling before CC has finished parsing it hangs in almost every case and has to be killed with kill -9

On fedora 64bit.

Assume this is separate issue, but got bit by this recently. Any word on a fix?

If I am not too impatient, I wait until CC has finished.
Or I disable it, but it is a helpful plugin when navigating through source-code.
No time to dig into it deeper.
It looks like a deadlock, because (normally or better in most or all cases) all threads are in a wait-state if that happens (wxSemaphore::Wait()).

[MortenMacFly]

Unfortunately, with the current trunk I can reproduce this crash on Windows. But for me it also crashes with CC disabled.

Basically I cannot shut-down C::B without crash after having loaded any project. Funnily, in the debugger it works.

[MortenMacFly]

Funnily, in the debugger it works.

Now it did, here the (not very helpfule) trace back:

[debug]#0  0x6274037a in ?? () from C:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll
[debug]#1  0x0043b864 in InfoPane::~InfoPane (this=0x1ef1ff8, __in_chrg=<optimized out>) at C:/Devel/CodeBlocks/src/src/infopane.cpp:61
[debug]#2  0x0043b901 in InfoPane::~InfoPane (this=0x1ef1ff8, __in_chrg=<optimized out>) at C:/Devel/CodeBlocks/src/src/infopane.cpp:63
[debug]#3  0x62878cec in ?? () from C:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll
[debug]#4  0x62701242 in ?? () from C:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll

(Jens: I didn't apply our patch yet.)

[Jenna]

Did you double-check, that commit 8395 is applied correctly (so that it reverted 8391) ?
Full rebuild, pch's ... ?
gcc 4.6 or 4.7, which wxWidgets ?

[MortenMacFly]

Did you double-check, that commit 8395 is applied correctly (so that it reverted 8391) ?

I think that was it: in main.cpp I forgot to sync the Manager shutdown changes (main.cpp is heavily modified in my local copy). I'll report back...

Full rebuild, pch's ... ?
gcc 4.6 or 4.7, which wxWidgets ?

Yes, yes, gcc 4.7, wxWidgets 2.8.12.