News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

Constant hang with 7763

Started by ironhead, February 01, 2012, 10:45:06 PM

Previous topic - Next topic

ironhead

I've updated to the latest svn version (7763 as of this post) and it constantly hangs when CC is supposed to kick in (i.e. on the 3rd character).  I've done a '--debug-log-to-file' but since I have to kill the codeblocks.exe process, it's a truncated file (at 4096 bytes).  Is this a known issue?

I'm running codeblocks self compiled using MinGW gcc 4.6.2 on Windows XP Pro SP3.

ollydbg

#1
I can confirm it hangs (Even in a very simple tiny code snippet)

I try to find the reason, but no success.

1, I debug it under gdb, and when it hangs, I pause the gdb, and check all the threads and call stack, I only find one:

One thread is halted in:
[debug]#5  0x65ed5270 in CodeCompletion::CodeComplete (this=0x3b9f458) at E:\code\cb\cb_trunk\src\plugins\codecompletion\codecompletion.cpp:968
Here is a cs enter, so the main GUI hangs.
The other thread has no useful information.

2, I try to enable the "#define CC_ENABLE_LOCKER_TRACK", and add '--debug-log-to-file', but when viewing the debug log file, I can't find anything wrong, the last message is:

....
s_TokensTreeCritical.Enter() : ExpandItem(), E:\code\cb\cb_trunk\src\plugins\codecompletion\classbrowserbuilderthread.cpp, 1040
s_TokensTreeCritical.Entered() : ExpandItem(), E:\code\cb\cb_trunk\src\plugins\codecompletion\classbrowserbuilderthread.cpp, 1040
s_TokensTreeCritical.Leave() : ExpandItem(), E:\code\cb\cb_trunk\src\plugins\codecompletion\classbrowserbuilderthre


The ugly thing is: The main GUI hangs, so the cc_logger does not work anymore. :(

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Jenna

It does not hang here, neither on linux nor win7.

Did you do a real clean rebuild. I mean manually cleaned (devel, output, .objs and include/*.gch) to be absolutely sure no artefacts of a prior build are left ?
Or a fresh and clean svn checkout ?

MortenMacFly

Quote from: jens on February 02, 2012, 06:30:59 AM
It does not hang here, neither on linux nor win7.
Not here, too. You can try to add a #define CC_ENABLE_LOCKER_ASSERT in the compiler options of the CC target and re-compile this plugin. If it still hangs, it should not be the lockers.
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]

ollydbg

#4
I did a clean build. The strange thing is:
if I run the new build c::b under c::b, then the new c::b will hang.
If I run the new c::b separately, it does not hang.

EDIT both cases hang.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ironhead

Quote from: jens on February 02, 2012, 06:30:59 AM
It does not hang here, neither on linux nor win7.

Did you do a real clean rebuild. I mean manually cleaned (devel, output, .objs and include/*.gch) to be absolutely sure no artefacts of a prior build are left ?
Or a fresh and clean svn checkout ?

Odd, it hangs all the time for me.  This is on a fresh svn checkout (no previous builds done in the local repository).

ollydbg

Quote from: MortenMacFly on February 02, 2012, 07:40:25 AM
You can try to add a #define CC_ENABLE_LOCKER_ASSERT in the compiler options of the CC target and re-compile this plugin. If it still hangs, it should not be the lockers.
It still hangs here(Windows XP) if I enable CC_ENABLE_LOCKER_ASSERT, so where is bug come from???

I fix a build error when enable CC_ENABLE_LOCKER_ASSERT in rev 7765.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ironhead

#7
I defined both CC_ENABLE_LOCKER_ASSERT and CC_ENABLE_LOCKER_TRACK in the code-completion target, executed a complete rebuild (after updating to 7765) and now C::B crashes whenever I load a project file.  I've attached the .RPT file for reference.

edit: I removed CC_ENABLE_LOCKER_TRACK and I'm now back to the original behaviour, in that C::B hangs when the CC list is supposed to show (this is with CC_ENABLE_LOCKER_ASSERT defined).

MortenMacFly

Quote from: ironhead on February 02, 2012, 04:29:02 PM
I defined both CC_ENABLE_LOCKER_ASSERT and CC_ENABLE_LOCKER_TRACK in the code-completion target, executed a complete rebuild (after updating to 7765) and now C::B crashes whenever I load a project file.  I've attached the .RPT file for reference.
OK - I was able to reproduce and fixed that. In addition I also fixed the permanent ClassBrowserBuilderThread lock-up. However, for the latter I need some more time as there is one annoyance, so I won't commit.

Please revert (only CC!) to r7658 (maybe r7723 works, too) to fix. CC on trunk is not stable atm.
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]

ironhead

I can confirm that 7766 fixes the hang.  I look forward to testing the other fixes when they are ready. ;)

ollydbg

Quote from: MortenMacFly on February 03, 2012, 12:36:08 AM
Quote from: ironhead on February 02, 2012, 04:29:02 PM
I defined both CC_ENABLE_LOCKER_ASSERT and CC_ENABLE_LOCKER_TRACK in the code-completion target, executed a complete rebuild (after updating to 7765) and now C::B crashes whenever I load a project file.  I've attached the .RPT file for reference.
OK - I was able to reproduce and fixed that.
Confirm the fix, thanks!!!
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.