Is CC crash, or Debugger plugin?

[MortenMacFly]

I was editing the source code. Almost all crashes/lockups happen after I've edit the source code.

Just for convenience: Can you try if theses crashes still happen if you disable the real-time parsing? I would guess it'll be way more stable then.

[oBFusCATed]

Yes, I've disabled 'Update parse when typing', I hope this is what you mean by real time parser.

[MortenMacFly]

Yes, I've disabled 'Update parse when typing', I hope this is what you mean by real time parser.

Yes, that's what I meant. So the kick-in is not caused by that. :-(

[oBFusCATed]

....So the kick-in is not caused by that. :-(

My mistake, I should have said - "I've just disabled it, lets see if the crashes are happening still!"

[oBFusCATed]

The "calltip crash" (the one in the std::set), just happened, so it is not related to the realtime parser.

This time it happened during debugging (99% of the time it was during debugging, but I guess this is just caused by the usage pattern).

Maybe it is time to start running it under valgrind.

[Loaden]

The "calltip crash" (the one in the std::set), just happened, so it is not related to the realtime parser.

This time it happened during debugging (99% of the time it was during debugging, but I guess this is just caused by the usage pattern).

Maybe it is time to start running it under valgrind.

I don't know how to use valgrind.
Maybe it is time to disable the option: "Compiler and debugger settings > Debugger settings > Evaluate expression under cursor"  ?
:lol:

[oBFusCATed]

Or you should fix the bug  

Do you have anymore CC fixes in the pipeline or it is safe to do a merge?

p.s. you should try it (valgrind) it is pretty powerful and not that hard (on smaller projects, C::B is a bit biggish)

[Loaden]

Maybe it is time to start running it under valgrind.

I can't run Valgrind plugin in CB, here is the error log:

valgrind --version
valgrind-3.6.1
valgrind --leak-check=yes --xml=yes --xml-file=ValgrindOut.xml "devel/codeblocks" --debug-log --multiple-instance -ns -ni
devel/codeblocks: error while loading shared libraries: libcodeblocks.so: cannot open shared object file: No such file or directory

Then I run valgrind in bash:

Code Select Expand

#!/bin/sh
APP_DIR=`dirname "$0"`
APP_DIR=`( cd "$APP_DIR" && pwd )`
export LD_LIBRARY_PATH=$APP_DIR:$LD_LIBRARY_PATH
valgrind --leak-check=yes --xml=yes --xml-file=ValgrindOut.xml $APP_DIR/parsertest $@
And I can't find any issue.


[attachment deleted by admin]

[oBFusCATed]

It is better to run in from the command line.
Something like valgrind --leak-check=full ./app
Also try running it on the parsetest project.
Also look at the threaded engines of valgrind:
http://valgrind.org/docs/manual/hg-manual.html
http://valgrind.org/docs/manual/drd-manual.html

[Loaden]

Valgrind can not give me any useful advise.
You can try REV7309, and disable the new option "Enable headers code-completion".
Maybe the issue is related with it.

[oBFusCATed]

Do you see any "uninitialized write" kind of messages?

OK, when I get home all, merge the code in the branch and will do some testing.

[Loaden]

Do you see any "uninitialized write" kind of messages?

No.

valgrind --version
valgrind-3.6.1
valgrind --leak-check=full --xml=yes --xml-file=ValgrindOut.xml "devel/codeblocks" --debug-log --multiple-instance -ns -ni

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:13539): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

[oBFusCATed]

Loaden: Why are you using --xml=yes and --xml-file? They are ment for application parsing, not human parsing.

[Loaden]

Loaden: Why are you using --xml=yes and --xml-file? They are ment for application parsing, not human parsing.

I am using CB's Valgrind plugin.
It's works now.

[oBFusCATed]

Try from the command line, there is more output there.

And you're trying it on a big project for long time? If you just start C::B move around for a minute and quit, you'll find nothing.