Author Topic: The 15 August 2011 build (7385) is out.  (Read 181096 times)

Offline ham

  • Multiple posting newcomer
  • *
  • Posts: 23
Re: The 15 August 2011 build (7385) is out.
« Reply #15 on: August 17, 2011, 10:20:36 pm »
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

Offline samho5888

  • Single posting newcomer
  • *
  • Posts: 2
Re: The 15 August 2011 build (7385) is out.
« Reply #16 on: August 18, 2011, 09:47:16 am »
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

     

Offline Zenju

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 15 August 2011 build (7385) is out.
« Reply #17 on: August 18, 2011, 05:08:48 pm »
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)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12597
    • Travis build status
Re: The 15 August 2011 build (7385) is out.
« Reply #18 on: August 18, 2011, 05:12:16 pm »
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?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Zenju

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 15 August 2011 build (7385) is out.
« Reply #19 on: August 18, 2011, 05:35:29 pm »
Quote
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!

Quote
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

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 15 August 2011 build (7385) is out.
« Reply #20 on: August 18, 2011, 05:42:58 pm »
Quote
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?

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: The 15 August 2011 build (7385) is out.
« Reply #21 on: August 18, 2011, 06:08:57 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12597
    • Travis build status
Re: The 15 August 2011 build (7385) is out.
« Reply #22 on: August 18, 2011, 06:20:44 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Zenju

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 15 August 2011 build (7385) is out.
« Reply #23 on: August 18, 2011, 08:35:01 pm »
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:

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12597
    • Travis build status
Re: The 15 August 2011 build (7385) is out.
« Reply #24 on: August 18, 2011, 09:48:15 pm »
No, you can't build it with vc10, but you can build it with mingw and then debug with gdb.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Zanzicas

  • Single posting newcomer
  • *
  • Posts: 2
Re: The 15 August 2011 build (7385) is out.
« Reply #25 on: August 22, 2011, 04:34:43 pm »
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.

Offline Micool121

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 15 August 2011 build (7385) is out.
« Reply #26 on: August 23, 2011, 12:05:55 am »
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*'

Offline spectre

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 15 August 2011 build (7385) is out.
« Reply #27 on: August 23, 2011, 11:31:42 am »
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]

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: The 15 August 2011 build (7385) is out.
« Reply #28 on: August 23, 2011, 01:42:53 pm »
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.
« Last Edit: August 23, 2011, 01:45:06 pm by Folco »
Kernel Extremist - PedroM power

Offline Micool121

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 15 August 2011 build (7385) is out.
« Reply #29 on: August 23, 2011, 02:36:03 pm »
Folco, this may have the same root cause than the bug of the '*NONE* 'parser ,from the symbol browser we spoke before ?