The 25 september 2010 build (6634) CODECOMPLETION BRANCH version is out.

[jens]

What is the meaning about this log?

** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]

** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed

I think it is related to gtk/wxgtk, but unfortunately google says nothing special about that message.
I don't remember if I see it earlier but I don't run C::B in console or in gdb very often.

I don't get it here (debian 64-bit unstable/experimental mix).
Errors like this are often caused by gtk2-changes.
Which OS are you on and what is the version of libgtk2 ?
 

[jens]

Hi,
I have following segfaults when loading some big project ~800k LOC /
~3000-4000 files (but about 10 files are opened) with C::B version 10.05cc6634-1
from Jens repository (CC branch). I have it usually three times on five C::B starts.

I don't get a segfault, but cc seems to either hang in a loop or do nothing (C::B is responsible), but it starts parsing and I never get a message that parsing ends.
Do nothing is not correct, because it uses cpu-power and memory (see below).

I also do not get any entries in symbols-browser.
These are the last lines of the debug-output:
Passing list of files to batch-parser.

Code: [Select]

Header to parse up-front: '/usr/include/c++/4.4/cstddef'
Header to parse up-front: '/usr/include/boost/config.hpp'
Header to parse up-front: '/usr/include/boost/filesystem/config.hpp'
Add up-front parsing 3 file(s) for project 'test'...
Add batch-parsing 21641 file(s) for project 'test'...
Create new parser for project 'test'
Starting batch parsing for project 'test'...

It's just a really large dummy project:
linux kernel 2.6.29 with all files added to an empty project.
More than 21500 files, nearly 10 million lines of code (more than 6 million pure code and nearly 400 k comment and code mixed).
It uses 100% of one of my cpu's and uses more than 1.1 GB of my memory, but it seems to never end parsing.
I wait if it stops somewhen in the future, and edit this post if it happens (or if it crashes).

By the way, why are boost-headers listed here (I don't think linux-kernel uses them) ?

[polygon7]

What is the meaning about this log?

** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]

** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed

I think it is related to gtk/wxgtk, but unfortunately google says nothing special about that message.
I don't remember if I see it earlier but I don't run C::B in console or in gdb very often.

I don't get it here (debian 64-bit unstable/experimental mix).
Errors like this are often caused by gtk2-changes.
Which OS are you on and what is the version of libgtk2 ?
 

It is Ubuntu 10.10 (x86) and libgtk2 version is 2.20.0-0ubuntu4 (probably, because I don't have
access to this computer at this moment - It is in my work office, and I'm on holiday (hurray! ;-D) ).

[Loaden]

1. support typedef of template operator overloading by blueshake, see http://forums.codeblocks.org/index.php/topic,13390.msg90193.html#msg90193 for more details.
2. fix a bug of the default parameter error in MarkItemsByAI, Now CC Search gives correct matching result.
3. improved Code-refactoring model, now it is 20X faster when verifying the search result.
4. improved template value-tooltip (typedef of template shows correct information).
5. support reparsing file after the editor modified.

[jens]

After more than 7 hours I tried to stop my experiment.
C::B used constantly about 100 % of my one cpu and memory usage increased to more than 2.2 GB.

I tried to close C::B the normal way, cpu usage reached 179 %:
After some minutes I got the message Removed test from all deps.
Memory usage was stable at 2.2 GB, cpu-usage went back to 100 % and nothing happens.
I had to kill C::B to finally close it.

"Smaller" projects like C::B are no problem.

I think I found the cause for the hang and the place, where it happens.
I will post more informations later.

[M0str3nc0]

Hi Everyone.

No so sure if this is the right place: I want to "improve" wxWidgets by including the newest version 2.9.1

How can I do that using the Nightly ?? Also, I carry my CodeBlocks =) =) in a USB memory because it helps me to practice C++ whenever I needed. I already downloaded wxWidgets 2.9.1 but is made from many folders and files, not just a DLL.

Any advice please ??

Thank you in advance.

M0str3nc0.

[ollydbg]

I think I found the cause for the hang and the place, where it happens.
I will post more informations later.

@jens:
Nice catch, hopefully we can fix it by your information.

[ollydbg]

How can I do that using the Nightly ??

Don't understand your problem.
to compile wxwidgets 2.9.1, search the forum and there are some discussion.
to use a portable CB, there are some info in wiki and forum.

[Loaden]

Use real case sensitive when code completion.
If the case sensitive option checked, could be show "testFunc" only.

Code: [Select]

void testFunc();
void TestFunc();
tes| // only show "testFunc" now

[jens]

It's in fact an endless loop cc runs in:

Code: [Select]

ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
Happens in tokenizer.cpp in CalcConditionExpression after call of ReplaceBufferForReparse in

Code: [Select]

else if (!tk->m_Args.IsEmpty()).

The internal data of m_Buffer (assigned to p in ReplaceBufferForReparse) is filled with more and more ")" characters or exactly "0x29 0x00 0x00 0x00" as it's wxChar, these characters are shown if I add a watch for p ( "')' repeats 191 times" ), but are not visible if I add a watch for m_Buffer, what seems strange, because in both cases gdb shows the value of m_Buffer.m_pchData .
Adding a watch for m_Buffer.m_pchData directly shows the same content as p.
With every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used im my test).

I tried to strip down the sources to get a small shareable project, where that occurs, but I wasn't able to do so.
The only thing that happened was that C::B crashes with a segfault, when it tried to send the cbEVT_THREADTASK_ENDED in cbThreadPool::TaskDone without a usable backtrace, the same happens with kernel-sources from 2.6.35 kernel.

[ollydbg]

it should be a bug in Macro expansion related code. some infinite recursive macro replacement happens. like

AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...

With every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used in my test).

Macro expansion is just replace some characters in the m_Buffer.

Code: [Select]

xxxxxxxxxAAAA(u,v)yyyyyyyyy
For example, the above is a char Array m_Buffer, then "AAAA(u,v)" need to do a Macro expansion to some other text. So, we just do a "backward" text replace, so that, after replacement, The last replacement char was ")" in "AAAA(u,v)" (We say it as an entry point), so the text becomes:

Code: [Select]

xxxNNNNNNNNNNNNNNNyyyyyyyyy
Note that "NNNNNNNNNNNN" is some macro expansion text. then the m_TokenIndex was moved backward to the beginning of the text.
if the macro expansion result text is small enough, then m_Buffer's length do not need to change.

The situation when our m_Buffer's length need to be change is that the macro expansion text is too long, so the buffer before "entry point" can not hold the new text, this way, m_Buffer's length will adjusted. like:

Code: [Select]

NNNNNNNNNNNNNNNNNNNNNNyyyyyyyyy
Hope this helps to find the bug.

[Loaden]

It's in fact an endless loop cc runs in:

Code: [Select]

ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
Happens in tokenizer.cpp in CalcConditionExpression after call of ReplaceBufferForReparse in

Code: [Select]

else if (!tk->m_Args.IsEmpty()).

It shoud be fixed by this patch.
Thanks!

[Loaden]

AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...

Yes, like this, AAA is macro, and BBB is argument. I can't write a sample too.
But i find the reason, and avoid the endless loop.

[jens]

it should be a bug in Macro expansion related code. some infinite recursive macro replacement happens. like

AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...

With every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used in my test).

Macro expansion is just replace some characters in the m_Buffer.

Code: [Select]

xxxxxxxxxAAAA(u,v)yyyyyyyyy
For example, the above is a char Array m_Buffer, then "AAAA(u,v)" need to do a Macro expansion to some other text. So, we just do a "backward" text replace, so that, after replacement, The last replacement char was ")" in "AAAA(u,v)" (We say it as an entry point), so the text becomes:

Code: [Select]

xxxNNNNNNNNNNNNNNNyyyyyyyyy
Note that "NNNNNNNNNNNN" is some macro expansion text. then the m_TokenIndex was moved backward to the beginning of the text.
if the macro expansion result text is small enough, then m_Buffer's length do not need to change.

The situation when our m_Buffer's length need to be change is that the macro expansion text is too long, so the buffer before "entry point" can not hold the new text, this way, m_Buffer's length will adjusted. like:

Code: [Select]

NNNNNNNNNNNNNNNNNNNNNNyyyyyyyyy
Hope this helps to find the bug.

The cause for the growing m_Buffer is, that in every loop one of the two replacements made needed 10 bytes, but m_TokenIndex is 9, so one space is prepended.
As posted there are thousnads (after some times millions of colsing brackets visible in m_pchData but not seen by our function to display wxString's in gdb.

@ Loaden:
I test the patch and give you feedback.

[jens]

@ Loaden:
I test the patch and give you feedback.

First endless-loop seems to be fixed, now we get one some lines later.

Code: [Select]

ReplaceBufferForReparse() : <FROM>printf<TO>printk
ReplaceBufferForReparse() : <FROM>printk<TO>printf
tk->m_Type is printf and token is printk and vice versa.

Can this be handled in ReplaceBufferForReparse, so it only has to be done in one place ?