C::B svn6346 hang report always on closing

[Deschamps]

Hello.

I've recently built C::B from svn repository (revision 6346) and now I'm receiving a report from Bug Buddy about a supposed hang every time I close the application. I've noticed this after "uninstalling + updating sources + cleaning + bootstrapping + configuring and making (with all contrib plugings)" from svn repository.

With revision 6336 (the last I compiled before this one), all was working fine and no report of this kind was noticed.

However, I must say that C::B is doing his job perfectly in any case, and looking for any Code::Blocks related process after this bug report (ps -d | grep code) didn't find anything. So that, I'm not sure about the likeliness of this report.

My current environment: Arch Linux i686, GNOME 2.30-1, gcc 4.5.0 20100520, wxGTK 2.8.11

Attached is the complete report generated by Bug Buddy.

Thanks, and kindest regards.


[attachment deleted by admin]

[Jenna]

Are you sure you removed the old pch's.
That does not always work reliable if some headers have changed.
And we have had sdk changes in 6339.

[gd_on]

Hi,
I have a (small) problem when re-building entirely svn 6346 (on Windows XP SP3) : I obtain for a lot of compilation a Warning message saying :

warning: C:\CodeBlocks_SVN\CodeBlocks_src\src\include/sdk.h.gch: not used because `wxPG_USE_WXMODULE' not defined

but apparently, it finally works.

Could it be a similar problem, so may be I must first delete sdk.h.gch and sdk_precomp.h.gch ?

gd_on

[Jenna]

You should try to do so.

If we have massive sdk-changes (in this case wxPropgrid is moved to sdk) I delete devel, output and include/*.gch to be sure everything is linked correctly.

[gd_on]

Hi again,
I tried to to that, to have a really fresh rebuild. But I obtain always the same messages on some compilations, but I think less than before (for example still in Code Snippets).
May be a new problem because I use now tdm gcc 4.5. But
As I said, not a great problem, because C::B is finally correctly compiled (I think  :?).

gd_on

[Jenna]

Hi again,
I tried to to that, to have a really fresh rebuild. But I obtain always the same messages on some compilations, but I think less than before (for example still in Code Snippets).
May be a new problem because I use now tdm gcc 4.5. But
As I said, not a great problem, because C::B is finally correctly compiled (I think  :?).

gd_on

These messgages come, because pch's can only be used with the same defines as they have been built. It should have nothing to do with gcc 4.5.

[Deschamps]

Hi again.

Well, the situation continued after trying a cleaned rebuild with newer revisions, so I uninstalled and erased all, building C::B from scratch, from svn r6379 sources just checked out. And still I'm receiving that hang report on closing the IDE.

So I'll try to compile in a while an old sources revision (I think that rev6336 and older were closing fine) so I could assume that it's not a C::B behavior, but something in my box causing this issue.

Regards.

[Deschamps]

Ok. I've just downloaded from the repository and compiled C::B rev.6336 sources, with the hope that it would show the same hang warning I've been receiving these weeks each time I was exiting the IDE, thinking that this could let me confirm that there is something wrong with my Archlinux distribution... But, nope! C::B svn r6336 is closing without problems nor hang reports.

So that, now I'm sure that there is something that I've not identified between rev.6336 and rev.6346 (and maintained in later revisions) that makes BugBuddy to throw a hang report each time C::B is closed, at least for my environtment.

Regards.

[oBFusCATed]

Can you try to build codeblocks with --enable-debug?
Then run gdb codeblocks and when cb crashes, execute the bt command in gdb.

There is a possibility for a crash if a plugin (or someone else I don't remember the details) writes something to the log during the shutdown of CB.

[ollydbg]

Can you try to build codeblocks with --enable-debug?
Then run gdb codeblocks and when cb crashes, execute the bt command in gdb.

There is a possibility for a crash if a plugin (or someone else I don't remember the details) writes something to the log during the shutdown of CB.

--enable-debug  is a option to let Codeblocks open a debug log panel.

In windows, CB is always build with debug information, so, you can debug CB under CB, if the debugee CB crashes, the debugger CB can get the call stack information

[Jenna]

Can you try to build codeblocks with --enable-debug?
Then run gdb codeblocks and when cb crashes, execute the bt command in gdb.

There is a possibility for a crash if a plugin (or someone else I don't remember the details) writes something to the log during the shutdown of CB.

--enable-debug  is a option to let Codeblocks open a debug log panel.

In windows, CB is always build with debug information, so, you can debug CB under CB, if the debugee CB crashes, the debugger CB can get the call stack information

That's not correct !!

--enable-debug is an option of the configure-script linux !
The option you mentioned is --debug-log or -d on commandline and has nothing to do with it.
On linux I suggest not to use it, because C::B's internal debug-output is written to the console if the debug-log is not used. If it is used the information is lost after a crash. You have to start C::B from console to see it of course.

@Deschamps:

if you rebuild C::B, you can turn on additional debug-logging in OnInit() in app.cpp, change the parameter of wxLog::EnableLogging(false); to true before the build and you get some warnings that can be ignored and possibly (hopefully) some more information.

[ollydbg]

Can you try to build codeblocks with --enable-debug?
Then run gdb codeblocks and when cb crashes, execute the bt command in gdb.

There is a possibility for a crash if a plugin (or someone else I don't remember the details) writes something to the log during the shutdown of CB.

--enable-debug  is a option to let Codeblocks open a debug log panel.

In windows, CB is always build with debug information, so, you can debug CB under CB, if the debugee CB crashes, the debugger CB can get the call stack information

That's not correct !!

--enable-debug is an option of the configure-script linux !
The option you mentioned is --debug-log or -d on commandline and has nothing to do with it.
On linux I suggest not to use it, because C::B's internal debug-output is written to the console if the debug-log is not used. If it is used the information is lost after a crash. You have to start C::B from console to see it of course.

I'm sorry, that was my big Mistake. 

[Deschamps]

Hello again.

There are some changes in regards to my last post. The situation has maintained at least until revision 6400, but I've recently compiled svn revision 6425 (with wxSmith and related plugins -wxSmithAUI and wxsmithcontribitems- disabled due to the different version for the C::B SDK), and all is going fine. No more hang reports from BugBuddy each time I was closing Code::Blocks.

Good news at last.

But, I don't know if this is because wxSmith is disabled (this will be easily checked), or some change has solved this problem between revs 6400 and 6425, or because this was caused by my environment, who has also been updated (kernel 2.6.34, gcc 4.5.0 20100610 and GNOME 2.30-2).

The fact is that C::B is not throwing hang reports anymore

Kindest regards.