Release 15.12, RC1 has arrived

[CuteAlien]

Assert (without crash) after doing very long nothing with c::b, followed by Find in files over workspace files and then double-clicking one of the results):

ASSERT INFO:
../include/wx/dynarray.h(838): assert "uiIndex < m_nCount" failed in Item().

BACKTRACE:
[1] wxGenericTreeCtrl::CalculateLevel(wxGenericTreeItem*, wxDC&, int, int&)
[2] wxGenericTreeCtrl::CalculatePositions()
[3] wxGenericTreeCtrl::DoDirtyProcessing()
[4] wxGenericTreeCtrl::OnInternalIdle()
[5] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[6] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[7] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[8] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[9] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[10] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[11] wxFrame::SendIdleEvents(wxIdleEvent&)
[12] wxAppBase::ProcessIdle()
[13] wxApp::DoIdle()
[14] g_main_context_dispatch
[15] g_main_loop_run
[16] gtk_main
[17] wxGUIEventLoop::DoRun()
[18] wxEventLoopBase::Run()
[19] wxAppConsoleBase::MainLoop()
[20] CodeBlocksApp::OnRun() /tmp/buildd/codeblocks-13.12svn10621/src/src/app.cpp:852
[21] wxEntry(int&, wchar_t**)
[22] main /tmp/buildd/codeblocks-13.12svn10621/src/src/app.cpp:322
[23] __libc_start_main

Build: Dec 10 2015, 22:09:58 - wx3.0.2 (Linux, unicode) - 64 bit
On Debian stable.

edit: Got the same assert with same callstack later on when switching betwen files by clicking a tab. So it's maybe related to bringing some file to the front in the editor. Also not just getting it once but maybe 5 times in a row.

[oBFusCATed]

Do you have the option to sync the editor and the project tree enabled?

Also can you share your project or checkout the codeblocks' source code and try to reproduce it with some of the projects or workspaces in it?

edit: Also have you added or removed some files to the workspace projects between the find in files and double clicking results?

[CuteAlien]

Do you have the option to sync the editor and the project tree enabled?

Hm, help me - I'm not finding that option so far.

Also can you share your project or checkout the codeblocks' source code and try to reproduce it with some of the projects or workspaces in it?

The project I've been working on is this one: https://bitbucket.org/mzeilfelder/trunk_hc1
But I fear it's not that easy to set-up, I don't really expect you to do that :-)
I had also the Irrlicht engine project open the same time (the one in libs/irrlicht/source/Irrlicht in the h-craft project).
If I can figure out any way to reproduce this in a less random way I'll inform you. But so far the only common factor I found is that it's happening when a new file should be displayed in the editor (not even sure yet if it's also happening when the file was already open in the background).

edit: Also have you added or removed some files to the workspace projects between the find in files and double clicking results?

No, I didn't do that. 

[oBFusCATed]

Hm, help me - I'm not finding that option so far.

You'll know if you have this option enabled if when you switch between file the same file gets selected in the project tree.
The option is in Settings -> Editor -> General -> Other editor settings -> Synchronise editor with Project manager.

[CuteAlien]

Nice option. Didn't have it enabled, but definitely will enable it in future :-)
But I did have the "open file list" from the open files list plugin open. And that did synchronize already.

[CuteAlien]

Don't know if it's related to my asserts. But when I start codeblocks from console I get the following message right on start (before opening any projects):
(codeblocks:2292): Gtk-CRITICAL **: IA__gtk_tree_model_iter_nth_child: assertion 'n >= 0' failed

edit: I could reproduce the assert now once the same way as before. I opened codeblocks with 2 project and a few open files in the editor and the Open files list visible. Then worked for a few hours on other stuff just keeping it in background. Switched back to c::b did a global search for something - and got the assert again. The synchronize settings was again disabled.

[CuteAlien]

OK, it's not about time spend in background. It happens when the "Search results" box contains a result which needs no scrollbars. And then I make a new search which needs scrollbars - but just barely (like the result has 1-2 line more than what would fit in the window without scrollbars).  Doing that I could reproduce the assert now a few times. Searching again when the scrollbars are already there with same search won't give the assert again even when I try different sizes for the "Search results" window. Only when I clear it in between (using a new search which is found less often).

edit: Thinking about it some more - it could also have been affected by the file-order opened on clicking search-results. So the other part would just have been random. Because when I tested resizing the "Search results" dialog I also resized the editor window which was above.

[ollydbg]

I'm on the opposite.

Code completion works for me in your case. However, if do 'using namespace std' and 'vector<int> v', I won't get autocompletion.

BTW, I use CB RC1 on Windows XP.

Hello.

I have problem with code completion with this release.

When I type this code:

Code

#include <iostream>
#include <vector>

int main()
{
    std::vector<int> v;
    
    v.
    
    return 0;
}

and after v. I should get code completion.
BUT when I type using namespace std;
and just vector<int> v; then when I type v. everything works good.

Ctrl + Space doesn't work, reparsing project also doesn't work.

Why?

@ssawgift, both the two cases works fine here for the latest svn10625. Which compiler do you use?

[CuteAlien]

Another crash, unfortunately no crash-dialog this time. It happened when I started the debugger (gdb 7.7.1).
On console the last messages had been:

Switching layout to "GDB/CDB debugger:Default"
../src/gtk/colour.cpp(241): assert "IsOk()" failed in GetColor(): invalid colour
Trace/breakpoint trap

Also another problem twice today where the debugger froze - and caused C::B to freeze as well (no more screen updates). When killed the debugger manually (with killall gdb) then C::B continued to work again.

edit: Got another crash when starting the debugger. This time last messages had been:
Switching layout to "GDB/CDB debugger:Default"
../src/common/object.cpp(352): assert "m_count > 0" failed in DecRef(): invalid ref data count
*** Error in `codeblocks': malloc(): smallbin double linked list corrupted: 0x00000000023bbaf0 ***
Aborted

[ollydbg]

@ssawgift, both the two cases works fine here for the latest svn10625. Which compiler do you use?

I use gcc 4.9.3 built by MinGW-W64 project.
...

I just tested this compiler, and it works fine here on my system with the latest svn rev10626.
EDIT: I'm on my local c::b build against wx3.0.2

[CuteAlien]

Next crash - I had just started C::B a few seconds before and was modifying a comment in a header. No crash-dialog, just those messages on the console where I started codeblocks:

ClassBrowser::OnThreadEvent(): Updating class browser...
codeblocks: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
../src/common/debugrpt.cpp(453): assert "IsOk()" failed in AddContext(): use IsOk() first

[oBFusCATed]

@CuteAlien:
Posting these is not very useful. Can you start codeblocks under gdb and post full backtraces when something crashes. You'll have to install the debug info package for these to be meaningful.

I'm having some crashes when using cb built with wx3, too, so hopefully I'll be able to get a meaningful backtrace.

[CuteAlien]

Yeah, I feared that it's not enough information. My hope is only that some assert might seem familiar and for example gives you an idea about further asserts to add which get us closer.
I can try the gdb setup I guess. Thought I get the feeling the crashes are not exactly related to the actions I do when it crashes. Far too random and all over the place - and never reproducible. So likely even a callstack won't give the answer. But maybe more hints.

[CuteAlien]

OK, here's a crash with gdb callstack (was typing code in the editor):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f36f1f3c700 (LWP 11483)]
0x00007f36fec36428 in IsOk (this=0x4455f88) at ../include/wx/gdiobj.h:49
49      ../include/wx/gdiobj.h: No such file or directory.
(gdb) bt
#0  0x00007f36fec36428 in IsOk (this=0x4455f88) at ../include/wx/gdiobj.h:49
#1  wxWindowBase::GetBackgroundColour (this=this@entry=0x4455eb0) at ../src/common/wincmn.cpp:1588
#2  0x00007f36feb08270 in wxDCImpl::InheritAttributes (this=0x7f36d0205eb0, win=0x4455eb0)
    at ../src/common/dcbase.cpp:1031
#3  0x00007f36feb07f74 in wxNativeDCFactory::CreateClientDC (this=<optimized out>, owner=0x7f36f1f3b790,
    window=0x4455eb0) at ../src/common/dcbase.cpp:143
#4  0x00007f36feb0a090 in wxClientDC::wxClientDC (this=0x7f36f1f3b790, win=0x4455eb0)
    at ../src/common/dcbase.cpp:210
#5  0x00007f36fecbd907 in wxGenericTreeCtrl::CalculatePositions (this=this@entry=0x4455eb0)
    at ../src/generic/treectlg.cpp:3983
#6  0x00007f36fecbef40 in wxGenericTreeCtrl::DoDirtyProcessing (this=0x4455eb0)
    at ../src/generic/treectlg.cpp:4145
#7  0x00007f36cb3b2fc8 in ClassBrowserBuilderThread::BuildTree (this=this@entry=0x445d4d0)
    at classbrowserbuilderthread.cpp:566
#8  0x00007f36cb3b369a in ClassBrowserBuilderThread::Entry (this=0x445d4d0)
    at classbrowserbuilderthread.cpp:220
#9  0x00007f36fe0163a2 in wxThread::CallEntry (this=this@entry=0x445d4d0) at ../include/wx/thrimpl.cpp:356
#10 0x00007f36fe016c83 in wxThreadInternal::PthreadStart (thread=0x445d4d0) at ../src/unix/threadpsx.cpp:867
#11 0x00007f36fb78c0a4 in start_thread (arg=0x7f36f1f3c700) at pthread_create.c:309
#12 0x00007f36faa9b04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[oBFusCATed]

Oh, can you try to disable the symbol browser in the code completion settings?
This one is known to cause problems, because it calls gui functions in non-main-thread.