The 15 August 2011 build (7385) is out.

[ham]

hi, again,

i recognized something else with CC

if i like to choose a member of a enum, i can only do that by accessing the enums name, and not directly as it should be

i.e. to get irr::video::EDT_NULL i have to access by irr::video::E_DRIVER_TYPE::EDT_NULL
and then delete E_DRIVER_TYPE::, because EDT_NULL is not in CC list

thx people

[samho5888]

Hi,
  I use .cbp generated from cmake-2.8.5 (win32),
and opened by C::B r7385, then the files does not show out all and just some like
-Workspace
 - myPrj
   - ..
     - ..
     - app
       + src
   + CMake Files

By using r7288 is OK.
What does I miss on new release?
Thanks

     

[Zenju]

There are serious multithreading issues with this release, the applications dead-locks reliably after approx. 30 seconds while doing nothing in particular, just reading source code. I don't know if this has to do with the new spellchecker (which I have disabled).

Please review the changes since the last fully working release, "20 July 2011 build (7289)". In this current form I cannot use the IDE at all and had to go back to an older version.

Another obvious, but less severe bug: Start CB and immediately(!) close it. This will make it crash. Maybe fixing this will cure other problems, too.

Regards, ZenJu

(Windows 7 x64)

[oBFusCATed]

Zenju:
Can you try to unload the codecompletion plugin and see if the dead locks are gone?
Does the deadlocks happen, when you use CC features?
Can you provide minimal files, which crash/deadlock C::B?

[Zenju]

Zenju:
Can you try to unload the codecompletion plugin and see if the dead locks are gone?
Does the deadlocks happen, when you use CC features?

Indeed, codecompletion seems to blame! If I disable codecompletion, no more hangs!

Can you provide minimal files, which crash/deadlock C::B?

Steps to reproduce:
1. open some project. I can reproduce the hang with my own project files (https://sourceforge.net/projects/freefilesync/develop) as well as with a newly wxWigets project by going through the CB wizard.
2. open some .cpp file and change a few lines. It's sufficient to insert arbitrary spaces and newlines. Having something changed seems important. Don't save the changes.
3. Scroll up and down with "PageUp" and "PageDown" keys.

(Repeat 2 and 3 a few times and it will hang.)

Interestingly CPU consumption is at 0% during this hang, therefore my first thought was some deadlock.

Regards, ZenJu

[Loaden]

Zenju:
Can you try to unload the codecompletion plugin and see if the dead locks are gone?
Does the deadlocks happen, when you use CC features?

Indeed, codecompletion seems to blame! If I disable codecompletion, no more hangs!

Try to disable symbols browser?

[Loaden]

Steps to reproduce:
1. open some project. I can reproduce the hang with my own project files (https://sourceforge.net/projects/freefilesync/develop) as well as with a newly wxWigets project by going through the CB wizard.
2. open some .cpp file and change a few lines. It's sufficient to insert arbitrary spaces and newlines. Having something changed seems important. Don't save the changes.
3. Scroll up and down with "PageUp" and "PageDown" keys.

(Repeat 2 and 3 a few times and it will hang.)

I can't reproduce the hang on Linux Mint 11 x64 or Win7 x86.

[oBFusCATed]

I can't reproduce ...

This is the biggest problem with data races and all the other threading bugs....
They are very hard to reproduce reliably and sometimes they depend on the Moon's phase

BTW, you can try to debug C::B with some of the threading tools of  Valgrind. Probably you can learn a thing or two about your code.

[Zenju]

Is there some chance to build CodeBlocks with Visual Studio 2010? In this case I could debug and try to find at least the location of the hang.
On my PC it's trivial to reproduce, it just happens all the time  :shock:

[oBFusCATed]

No, you can't build it with vc10, but you can build it with mingw and then debug with gdb.

[Zanzicas]

Since SVN 7257 I have had random crashes.  I am on Windows XP SP2.  Very much like ZenJu above.

My steps to reproduce:
1. Load C::B and create a default console CPP application.
2. Close C::B.
3. Restart C::B.
4. Choose the "Symbols" tab and select "View Everything".
5. Open the main.cpp file that you just created (don't open the project, just the file).
6. Choose "Global Functions" under symbols.
7. Click on the main.cpp editor and try to edit the file... I press return after the opening bracket and start to type
   "int i" and C::B will lock. 

The lockup seems to happen more when I open a CPP file that is not part of the project.  I generally always have the symbols tab active.

[Micool121]

same bug here : CB is hanging when editing a file not part of the project :

When editing this new file in the same way than Zanzicas, CB log shows :

create new parser for project '*NONE*'
switch parser to project '*NONE*'

[spectre]

I have recently built C::B from the sources (SVN revision 7406) on my Ubuntu 10.04 x86-64 box and launched C::B under monitoring of ThreadSanitizer (http://code.google.com/p/data-race-test/), a data race detector built upon Valgrind on Linux.

I have performed all the steps Zanzicas described. C::B hung when I tried to open an external .c file while the project "sample1" was loaded. The project and the ThreadSanitizer logs are in the attached archives.

In cb_logs.7z, "terminal" subdirectory contains the commands I ran to launch ThreadSanitizer and C::B as well as the log output of the latter. ThreadSanitizer logs are in "tsan" subdirectory.

Logs #01 correspond to the creation of the project "sample1".
Logs #02 - doing the steps Zanzicas described while ThreadSanitizer was running in pure happens-before mode (possibly less false positives but may have missed some races).
Logs #03 - similar to #02 but ThreadSanitizer was running in hybrid mode (possibly more false positives but more races can be detected).

The logs show some possible races that involve code completion component. Perhaps, they are worth looking at.
Those complaining at g_slice_* might be benign races or false positives, or something else, these probably do not need so much attention now.

I hope this will help identify and fix the problems.

P.S. I do not observe these hangs in rev.7257 I currently use for my daily work, but I have not tested this revision with data race detection tools yet, only rev.7406.


[attachment deleted by admin]

[Folco]

I get a crash when opening a file with the "file" tab in the "Management" panel.

Reproductible:
always

Step to reproduce:
- launch C::B
- on the "start here" page, choose a project to open
- switch to the "Files" tab of the management panel
- choose a file by clicking it, and select "Open it inside the Code::Blocks editor", then OK
 => C::B hangs

Notes:
- if you don't open a project before that, ie you open just a file proposed by the "Start Here" page, or you don't open any file, it won't crah. The crash only happens when a project  is opened.
- top says that C::B doesn't use CPU when it hangs
- the crash doesn't happen if CC is disabled (sorry for the CC team which works hard ont it...)

System:
- Debian Squeeze 64 bits
- Package downloaded on the repository of Jens (nightly build). Sorry, I don't remember if I installed the Debug branch or the regular one.

[Micool121]

Folco, this may have the same root cause than the bug of the '*NONE* 'parser ,from the symbol browser we spoke before ?