News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

crashes, when loading a workspace and then closing CB

Started by killerbot, September 16, 2012, 06:57:19 PM

Previous topic - Next topic

killerbot

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

oBFusCATed

#1
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

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

#4
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


killerbot

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

oBFusCATed

Quote from: killerbot on September 16, 2012, 08:06:50 PM
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
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Alpha

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

#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:

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.

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  :D

MortenMacFly

Quote from: killerbot on September 16, 2012, 11:02:26 PM
I can confirm that the crash I mentioned is solved by your commit Jens. Well done  :D
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...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

dmoore

Quote from: jens on September 16, 2012, 07:37:02 PM
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?
Python plugins: [url="https://github.com/spillz/codeblocks-python"]https://github.com/spillz/codeblocks-python[/url]
Code::Blocks Daily Builds -- Ubuntu PPA: [url="https://launchpad.net/~damien-moore/+archive/codeblocks"]https://launchpad.net/~damien-moore/+archive/codeblocks[/url]