User forums > Using Code::Blocks

How to edit linux kernel sources with code::blocks ?

<< < (2/5) > >>

Brane2:
No. After compiling, all plugins were enabled and that didn't work.

After that, I disabled many of them and things started to work.

I gradually enabled all of the plugins and CB still works.

It seems as if the error manifests itself at specific plugin loading sequence...

Brane2:
I can't replicate starting condition.

I even unisntalled C::B, configured and compile dit again and it now works out of the box with all plugins enabled....  :? :)

Brane2:
Hmm.

I have just noticed that I can't really disable "valgrind" plugin since C::B crashes immediatelly after that.
I have noticed that before, but have thought that maybe it's some system critical plugin, but after a second thought it doesn't seem logical.
I don't use valgrind.

Now I am using svn copy of C::B ( v5170 ATM), compiled with gcc-4.3.1 on Linux, but those two parameters don0t seem to be crucial for this error - e have seen it n previous svn versions, compiled with gcc-4.2.4

Brane2:
Well, after bazzillion retries and even running whole thing under gdb all I can say it seems to be some race condition inside impore function.

I'm not much into C++ and wxwidgets and can not find my way through source, but:

- when it happens, error is manifested as an access to invalid memory location
- execution stack at error point never has any function that has to do with wxGTK whatsoever.
- error is not readily repeatable. Sometimes it happens, sometimes not. Sometimes it gets much more often if codeblocks is compiled with -O2 or higher, sometimes gcc version has significant difference ( it crashes more/less frequently etc)
-whatever I do, if I want to have a chance of succesfull kernel import, I have to have the system totally idle otherwise ( no browsing with Firefox, not even Firefox open, especially with some page with animation, javascripts etc).

Maybe it is due my Phenom with 4 cores and L3 cache ( if that makes any difference ).

Since that error started manifesting itself many months ago, I went through a few versions of practically every software I have on my machine ( Gentoo Linux 64bit , weekly update), so it is not likely that particular version of some system library is the culprit...

Dr.Optix:
It may be the TODO List plugin who made your C::B freeze. I'm not sure but I've seen that for one of my projects (around 30 files in total) it took quite longer to parse all the files to find TODO NOTE or FIXME information.

~Dr.Optix

Navigation

[0] Message Index

[#] Next page

[*] Previous page