User forums > Nightly builds

The 15 August 2011 build (7385) is out.

<< < (6/13) > >>

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 ?

Navigation

[0] Message Index

[#] Next page

[*] Previous page