6Symbols browser - the most annoying thing in C::B.
A
It wasn't wide enough and I tried to resize it. C::B crashed.
This is the output from C::B:
(http://img172.imageshack.us/img172/4713/010firstcrashwhenresizingthesymbolswindowuh1.th.png) (http://img172.imageshack.us/my.php?image=010firstcrashwhenresizingthesymbolswindowuh1.png)
Steps to reproduce
1. Open C::B
2. Go to File-> New -> Project
3. Choose Console Application
4. Complete the Wizard
5. In the Management window, double click on Sources->main.cpp
6. Click once in the editor window
7. Grab the separator that splits the editor from the symbols browser. Drag 5 cm left. Sometimes it crashes after the first drag and drop. If it didnt crash, drag the separator left one more time. It will crash with the above error message printed in the console.
If there is no project opened, moving the separator did not crash Code Blocks. Most of the times, you dont even have to open main.cpp and click in the window. Just create a new Console project and try to resize the Symbols browser. I always get the same error.
I even got this error when double-clicking on main.cpp, but I couldn't reproduce it.
On a different occasion, while editing the text and then resizing the Symbold Browser, I got this error:
CodeHowever, I couldn't reproduce this either.(codeblocks:4439): GLib-CRITICAL **: g_queue_push_head_link: assertion `link->next == NULL' failed
codeblocks: cairo-ft-font.c:678: _cairo_ft_unscaled_font_set_scale: Assertion `error == 0' failed.
Aborted
It is annoying the hell out of me. What is really scary is that so many people have pointed this out on the forum and the usual response is that it is a problem with libcairo and that it was fixed an eon ago.
http://forums.codeblocks.org/index.php?topic=3364.msg27925#msg27925
http://forums.codeblocks.org/index.php?topic=3738.msg29472#msg29472
Fair enough.
Are there any other additional debugging details I can give you? I rarely run gdb directly from command line, but I am sure I can work something out.
Kip
I just entered "bt" in GDB and that is the backtrace it spat out after C::B terminated. Is there a better way to get more detail?
I think we have found a pattern.
Kip
Ok, here's an interesting fact.No, it still crashes..
I disabled the Code completion plugin, and I did not have any crashes.
Scheduling all of them on only one core would be possible - but this decision is up to your system, Code::Blocks does not have any influence on that.
taskset 2 /usr/bin/codeblocks