Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: ramS on January 20, 2014, 07:12:14 pm

Title: Code blocks using too much cpu
Post by: ramS on January 20, 2014, 07:12:14 pm
I recently built code blocks from source(13.12) on a linux box(centos). Now when I load my project, code blocks is using too much cpu. The machine has 2 quad core cpus and I see two threads using 100% cpu. WHen I switched to the previous version (12-11-release8629) it behaves properly. Any ideas on what might be going on?

This is a 64bit build using wx2.8.12 and g++4.5.1.

Here is what I see on the terminal window
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/gcc-4.5.1/include/c++/4.5.1
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/gcc-4.5.1/include/c++/4.5.1/x86_64-unknown-linux-gnu
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/gcc-4.5.1/include/c++/4.5.1/backward
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/gcc-4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/include
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/gcc-4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/include-fixed
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/include
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/local/gcc-4.5.1/include
NativeParser::GetGCCCompilerDirs(): Caching GCC default include dir: /usr/include
NativeParser::DoFullParsing(): AddCompilerPredefinedMacros failed!
NativeParser::DoFullParsing(): Adding three kind of files to batch-parser
NativeParser::DoFullParsing(): Add priority header file: '/usr/local/gcc4.5.1/include/c++/4.5.1/cstddef'
NativeParser::DoFullParsing(): Add priority header file: '/usr/local/gcc-4.5.1/include/c++/4.5.1/cstddef'
NativeParser::DoFullParsing(): Add priority header file: '/usr/include/boost/config.hpp'
NativeParser::DoFullParsing(): Add priority header file: '/usr/include/boost/filesystem/config.hpp'
NativeParser::DoFullParsing(): Add 5 priority file(s) for project '********'...
NativeParser::DoFullParsing(): Added 1629 header&source file(s) for project '****' to batch-parser...
ClassBrowser::UpdateClassBrowserView(): No active project available.
NativeParser::CreateParser(): Finish creating a new parser for project 'xr-snap'
ClassBrowser::OnThreadEvent(): Updating class browser...
ClassBrowser::OnThreadEvent(): Class browser updated.
NativeParser::OnParserStart(): Starting batch parsing for project '******'...
The Parser is still parsing files. > Reasons:
- still system priority headers to parse
- still need to mark files as local
- thread pool is not done yet
The Parser is still parsing files. > Reasons:
- still system priority headers to parse
- still need to mark files as local
- thread pool is not done yet

Thanks
Ram
Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 21, 2014, 08:43:18 am
Definitely a bug in CodeCompletion Plugin, but I just don't know how to catch the bug. You can simple disable this plugin, but you also lose the feature it supplied. It is hard to produce a simple project which can cause such issue.
BTW: How long does the 100% CPU usage last?
Title: Re: Code blocks using too much cpu
Post by: ramS on January 21, 2014, 02:25:24 pm
It goes on indefinitely. I have reverted back to version 12.11 for now.
Title: Re: Code blocks using too much cpu
Post by: MortenMacFly on January 21, 2014, 03:30:48 pm
It goes on indefinitely. I have reverted back to version 12.11 for now.
It would be really nice if you could provide a minimal sample (a stripped version of your project?!) to reproduce...
Title: Re: Code blocks using too much cpu
Post by: Conker on January 22, 2014, 10:01:19 pm
Hi.
I'm using version codeblocks 13.12 on windows and have issue with codecompletion plugin as well. Took me awhile to track this down to codecompletion, because I'm new to this IDE . It started as random crashes on opening a project and adding files to it. To the point of rendering the whole IDE completely unusable.

Attached file that locks up IDE every time on my system, just by opening it and browsing for a few sec, when codecompletion plugin is on. No need for projects, it happens all the time on this particular file.

Advice : Disable the plugin ,until its fixed .

Regards
Title: Re: Code blocks using too much cpu
Post by: oBFusCATed on January 23, 2014, 01:17:53 am
I doubt it is just this file at least on my machine it behaves as expected and there are no strange things.
Some of the includes might cause this. Try to remove some of them to see which one is causing the problem.
Title: Re: Code blocks using too much cpu
Post by: Conker on January 23, 2014, 02:53:43 pm
try this new one http://www.sendspace.com/file/s9mpzg. I've added all the files.
steps to reproduce:
1.unzip directory
2.make sure that you have codecomplete enabled
3.open 386.c by clicking on it in Explorer or from inside IDE/File/Open
4.after file loaded, go to second line with down button - http://clip2net.com/s/6EHELo

*** EDITED

Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 23, 2014, 03:28:25 pm
try this new one http://speedy.sh/gkAjd/cc-crash.zip . I've added all the files.
...
Oh my god, you need to download an exe file named cc-crash.zip.exe....... I don't want to do that.
Please choose another file share site.
Title: Re: Code blocks using too much cpu
Post by: Conker on January 23, 2014, 03:35:52 pm
Haha, you're right. Those fishers. Edited and tested a new host.
Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 23, 2014, 04:09:27 pm
try this new one http://www.sendspace.com/file/s9mpzg. I've added all the files.
steps to reproduce:
1.unzip directory
2.make sure that you have codecomplete enabled
3.open 386.c by clicking on it in Explorer or from inside IDE/File/Open
4.after file loaded, go to second line with down button - http://clip2net.com/s/6EHELo

*** EDITED


I can confirm the hang bug.
Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 24, 2014, 04:04:59 am
Some debug realize that the parser go to an infinite loop around the file x86_ops_bit.h, and around line 133, which is in a macro definition.

Code
#define opBT(name, operation)                                                   \
        static int opBT ## name ## _w_r_a16(uint32_t fetchdat)                  \
        {                                                                       \
                int tempc;                                                      \
                uint16_t temp;                                                  \
                                                                                \
                fetch_ea_16(fetchdat);                                          \
                eaaddr += ((regs[reg].w / 16) * 2);     eal_r = eal_w = 0;      \
                temp = geteaw();                        if (abrt) return 0;     \
                tempc = (temp & (1 << (regs[reg].w & 15))) ? 1 : 0;             \
                temp operation (1 << (regs[reg].w & 15));                       \
                seteaw(temp);                           if (abrt) return 0;     \
                flags_rebuild();                                                \
                if (tempc) flags |=  C_FLAG;                                    \
                else       flags &= ~C_FLAG;                                    \
                                                                                \
                cycles -= 6;                                                    \
                return 0;                                                       \
        }                                                                       \
        static int opBT ## name ## _w_r_a32(uint32_t fetchdat)                  \
        {                                                                       \
                int tempc;                                                      \
                uint16_t temp;                                                  \
                                                                                \
                fetch_ea_32(fetchdat);                                          \
                eaaddr += ((regs[reg].w / 16) * 2);     eal_r = eal_w = 0;      \
                temp = geteaw();                        if (abrt) return 0;     \
                tempc = (temp & (1 << (regs[reg].w & 15))) ? 1 : 0;             \
                temp operation (1 << (regs[reg].w & 15));                       \
                seteaw(temp);                           if (abrt) return 0;     \
                flags_rebuild();                                                \
                if (tempc) flags |=  C_FLAG;                                    \
                else       flags &= ~C_FLAG;                                    \
                                                                                \
                cycles -= 6;                                                    \
                return 0;                                                       \
        }                                                                       \
        static int opBT ## name ## _l_r_a16(uint32_t fetchdat)                  \
        {                                                                       \
                int tempc;                                                      \
                uint32_t temp;                                                  \
                                                                                \
                fetch_ea_16(fetchdat);                                          \
                eaaddr += ((regs[reg].l / 32) * 4);     eal_r = eal_w = 0;      \
                temp = geteal();                        if (abrt) return 0;     \
                tempc = (temp & (1 << (regs[reg].l & 31))) ? 1 : 0;             \
                temp operation (1 << (regs[reg].l & 31));                       \
                seteal(temp);                           if (abrt) return 0;     \
                flags_rebuild();                                                \
                if (tempc) flags |=  C_FLAG;                                    \
                else       flags &= ~C_FLAG;                                    \
                                                                                \
                cycles -= 6;                                                    \
                return 0;                                                       \
        }                                                                       \
        static int opBT ## name ## _l_r_a32(uint32_t fetchdat)                  \
        {                                                                       \
                int tempc;                                                      \
                uint32_t temp;                                                  \
                                                                                \
                fetch_ea_32(fetchdat);                                          \
                eaaddr += ((regs[reg].l / 32) * 4);     eal_r = eal_w = 0;      \
                temp = geteal();                        if (abrt) return 0;     \
                tempc = (temp & (1 << (regs[reg].l & 31))) ? 1 : 0;             \
                temp operation (1 << (regs[reg].l & 31));                       \
                seteal(temp);                           if (abrt) return 0;     \
                flags_rebuild();                                                \
                if (tempc) flags |=  C_FLAG;                                    \
                else       flags &= ~C_FLAG;                                    \
                                                                                \
                cycles -= 6;                                                    \
                return 0;                                                       \
        }

opBT(C, ^=)
opBT(R, &=~)
opBT(S, |=)

And from the Parserthread, I see that the m_Str becomes a very big string, it becomes bigger and bigger in this infinite loop...
Code
[debug]> p m_Str
[debug]$3 = "int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int "...
[debug]>>>>>>cb_gdb:

$3 = "int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int int "...
> p m_Str.size()

[debug]> p m_Str.size()
[debug]$4 = 131788
[debug]>>>>>>cb_gdb:

But currently I don't find the deeper reason about this infinite loop.
Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 24, 2014, 04:18:16 am
Also, those two values are surely wrong.

Code
[debug]> whatis m_RepeatReplaceCount
[debug]type = size_t
[debug]>>>>>>cb_gdb:
[debug]> output &m_RepeatReplaceCount
[debug](size_t *) 0x90d7d70>>>>>>cb_gdb:
[debug]> output m_RepeatReplaceCount
[debug]65898>>>>>>cb_gdb:
[debug]> whatis savedReplaceCount
[debug]type = int
[debug]>>>>>>cb_gdb:
[debug]> output &savedReplaceCount
[debug](int *) 0xe09fca8>>>>>>cb_gdb:
[debug]> output savedReplaceCount
[debug]65896>>>>>>cb_gdb:

Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 24, 2014, 06:00:29 am
I add some sanity check for macro expansion code in rev 9601, this avoid the infinite loop, please test and report back, thanks.
Title: Re: Code blocks using too much cpu
Post by: Conker on January 29, 2014, 08:17:23 pm
Can you link me to the binary with that fix ?
Title: Re: Code blocks using too much cpu
Post by: ollydbg on January 29, 2014, 08:50:35 pm
Can you link me to the binary with that fix ?
http://forums.codeblocks.org/index.php/topic,18853.0.html
Title: Re: Code blocks using too much cpu
Post by: Conker on January 30, 2014, 12:44:42 pm
Seems to be OK now. But be sure to install wxWidget dll as well. Otherwise it will hang right after starting up.
Thanks for the fix.