how to get rid of contribs enabled ???

[tiwag]

i have serious problems with a C::B build on ubuntu 5.10 with contribs enabled.
every time when i close C::B, it crashes and can't save its configuration file default.conf

how do i get rid of contribs enabled

in the past i built C::B with
./configure --enable-contrib 


but now i want to revert this build option,

i tried:
./configure --disable-contrib 

i did a completely fresh svn-checkout, and after
./bootstrap
./configure

all contribs are build again ........ grrrrrrrrrrrrr     :x

where is this info stored, which file do i have to delete to get rid of these contribs enabled

any ideas?
thx

[Der Meister]

Are you really sure that the contrib-plugins are the reason for the crash? Did you disable them and tried again?
Anyway, could you run Code::Blocks within gdb to get a backtrace after the crash and post it here? I'm asking this because I got similar problems, but I'm not sure if it is a problem of Code::Blocks or of my system. Here is the thread where I reported this problem.
If your backtrace is similar to the one I reported I would assume that it is really a problem of Code::Blocks.

[thomas]

Are you using the very latest builds? A crash-on-close bug in EditorManager was fixed only 2 days ago.

[tiwag]

Did you disable them and tried again? ...

that's what i want to try , but no go until all plugins are present, because C::B invokes by default all of them if detected,
when i tried to disable any or all plugins, C::B crashes when trying to save the default.conf.

that's the reason, why i want to build it completely without contribs plugins in order to test if it crashes then too

[tiwag]

Are you using the very latest builds? A crash-on-close bug in EditorManager was fixed only 2 days ago.

svn 1701 - its VERY recent 

i have these ominous chrashes since the introduction of wxaui

[Urxae]

Did you try removing the respective shared libs from the plugins folder? They may not be rebuilt, just be left over from before.
make clean should also have worked (but probably not after a ./configure without --enable-contrib parameter)

[tiwag]

Did you try removing the respective shared libs from the plugins folder? They may not be rebuilt, just be left over from before.
make clean should also have worked (but probably not after a ./configure without --enable-contrib parameter)

i first tried with
make clean
sudo make uninstall

but then some libs were still left on the harddisk,

then i cleaned everything by hand in /usr/local/...
deleted my trunk directory and did a fresh svn checkout

then after
./bootstrap
./configure

the /src/plugins/contrib/Makefile and /src/plugins/contrib/Makefile.in and
their companions in the contribs subdirectories were generated too - so i was suspicious.

after
make
sudo make install

i found, that C::B was built without the contrib plugins. 

BUT - the  crashes are the same as before, 
attached is, what the Debug report "codeblocks" has generated ...

[attachment deleted by admin]

[tiwag]

now i ran C::B with gdb,

attached are the backtraces for

1.) just run CodeBlocks and exit by File->Quit
2.) run C::B, open a project and say File->Close Project

any ideas ??

[attachment deleted by admin]

[Der Meister]

Are you using the very latest builds? A crash-on-close bug in EditorManager was fixed only 2 days ago.

svn 1701 - its VERY recent 

i have these ominous chrashes since the introduction of wxaui

I can confirm that, I have these crashes, too.

1.) just run CodeBlocks and exit by File->Quit
2.) run C::B, open a project and say File->Close Project

The backtrace for the first test is exactly what I get. I didn't test the second one, but I would guess its the same result as you got.

Anyway, did the crash still occur if you modified your layout (so that Code::Blacks askes you if it should save the changes)?

[thomas]

wxApp::Yield() seems to appear quite a lot... let's hope this isn't a recursive Yield crash?  :?

Have you tried disabling code completion? It is the only one still using unsafe Yields.

[Der Meister]

The crash happend even with *no* plugin loaded. Thus I don't believe that code-completion is involved in this crash.

[thomas]

Think you could set a breakpoint into the first line of MainFrame::OnApplicationClose and then keep stepping into until the crash happens?

Should not take forever (maybe 100-200 steps), and might reveal the problem.

[Der Meister]

Well, I will test this, but you have to wait a bit. I don't have access to my linux-machine before friday afternoon.

[mandrav]

Could you update to 1702 and try again? I must have fixed it now.

[tiwag]

Could you update to 1702 and try again? I must have fixed it now.

test it soon - i'll report in approx. one hour ...

[tiwag]

ok - here it is   

what i did : a fresh install of C::B without contrib plugins
by using the following commands

make clean
make clean-zipfiles
sudo make uninstall
svn update  ->(to SVN rev 1702)
./configure
make
sudo make install


1.) then i ran C::B and got NO CRASHES by simply running and closing C::B 

2.) the next time i ran C::B and changed the toolbar positions and some other layout-changes,
closed C::B, saved the changed layout, and got NO CRASH

3.) the next time i ran C::B and opened a project, edited something, saved the files and the project
and closed the project (File->CloseProject). then C::B hangs and doesn't respond to anything,
all menu items are greyed out and you can't close it.

4.) then i ran C::B from gdb, first just running and closing, C::B exited normally,
the next time i opened a project and closed the project immediately - C::B hangs - no response to anything
from gdb i interrupted C::B by using C-c , and got then the backtrace.
attached is the gdb-log from this session.

HTH

ps. if i can test anything else, please post it here and explain what i've to do 

[attachment deleted by admin]

[Der Meister]

It is just an assumption but to me it looks as if during the normal deconstruction of all objects/plugins/etc. the codecompletion parser calls wxSafeYield and this functions then starts (through some other calls) a new message loop that has obviously nothing to do. Thus it waits for events that will never occour because everything is already disabled.

[thomas]

It is just an assumption but to me it looks as if during the normal deconstruction of all objects/plugins/etc. the codecompletion parser calls wxSafeYield and this functions then starts (through some other calls) a new message loop that has obviously nothing to do. Thus it waits for events that will never occour because everything is already disabled.

That's why I asked if you had tried disabling the code completion plugin. This is exactly what I suspected, too. And worse, in its log function, the code completion plugin uses a plain normal wxYield.

[tiwag]

with disabled Codecompletion-plugin i get this debug-report
when exiting C::B (File->Quit) after i previously had opened a project
and closed it by using (File->CloseProject).
(the same happens of course when i quit C::B without closing the project before)

the default.config file is not written and updated on the harddisk !




[attachment deleted by admin]

[thomas]

Hmm.. that's funny. I see a  CloseActiveProject in there...

You know, just the other day, I said "I wonder why CloseActiveProject does not crash every time, since EditorManager is freed before ProjectManager, but since it's been working all that time, ok then...".

Maybe your problem will be gone after updating to the latest release (if you manage to compile it... I have a problem with the newest wxAUI update).
Everything regarding  Managers has been rewritten for better performance and stability, including the order of deallocation, which is now in order of dependence.

EDIT:
Revision 1707 compiles fine again
So... let's see if the bug has silently gone away...

[tiwag]

...
Revision 1707 compiles fine again
So... let's see if the bug has silently gone away...

is rev 1707 known to build with linux too ?

[mandrav]

Finally fixed the hang in 1709

[Ceniza]

Well, but now 1710 is broken for Linux:

Code

configmanager.cpp:226: error: no 'ConfigManager* CfgMgrBldr::GetConfigManager(const wxString&)' member function declared in class 'CfgMgrBldr'
configmanager.cpp: In member function 'ConfigManager* CfgMgrBldr::GetConfigManager(const wxString&)':
configmanager.cpp:228: error: no matching function for call to 'CfgMgrBldr::Get()'
./configmanager.h:254: note: candidates are: static ConfigManager* CfgMgrBldr::Get(const wxString&)
configmanager.cpp: At global scope:
configmanager.cpp:232: error: no 'ConfigManager* CfgMgrBldr::Build(const wxString&)' member function declared in class 'CfgMgrBldr'
configmanager.cpp: In member function 'void ConfigManager::Delete()':
configmanager.cpp:593: error: no matching function for call to 'CfgMgrBldr::Get()'
./configmanager.h:254: note: candidates are: static ConfigManager* CfgMgrBldr::Get(const wxString&)
configmanager.cpp: In member function 'void ConfigManager::DeleteAll()':
configmanager.cpp:609: error: no matching function for call to 'CfgMgrBldr::Get()'
./configmanager.h:254: note: candidates are: static ConfigManager* CfgMgrBldr::Get(const wxString&)
make[4]: *** [configmanager.lo] Error 1

[tiwag]

 :shock: - dunno - it just now built fine at my machine ...

but i had to "make clean" before, otherwise i got some errors too ...

can you try please with "make clean" ?

[tiwag]

Finally fixed the hang in 1709

Hi Yiannis !
great work - the hang / crash is really fixed when closing C::B with an active project active !!!

but if you close the project by File->CloseProject and
afterwards close C::B by using File->Quit
the following debug-report appears (same as before your last changes from rev 1709)



[attachment deleted by admin]

[Ceniza]

Just checked out another copy and it compiled.

It seems like the build system for Linux needs some more tuning

[Game_Ender]

I compiled revision 1731 on Linux and I still get hangs/crashes on exit after I have opened a project, it works find if I don't have codecompletion on.  I will try again tomorrow with codecompletion off.

Has Code::Blocks officially frozen its features set in an effort to squash all the finals bugs before the full 1.0 release?  I really like Code::Blocks, I just need a stable version that can debug and has project dependencies (ie. One you can actually use for development).  I can't seem to find one right now.

[mandrav]

Has Code::Blocks officially frozen its features set in an effort to squash all the finals bugs before the full 1.0 release?

Not yet. We 're undergoing some major changes in the API so we don't have to break it later, after 1.0 is out.
But those linux crashes are going to be fixed soon so you 'll have your "stable" build

[Game_Ender]

Mandrav, thanks for the great IDE I don't mean to sound like I am demanding anything.  I was just wondering why Code::Blocks is going through all these changes after 2 release candidates. 

I have revision 1727 and Code::Blocks will close fine as long as I have not opened a project.  If I try to close it after I have opened a project it will hang at ~%100 cpu usage.  I ran it through gdb and intreputed the program during the hand.  The first run has CodeCompeletion disabled through the menu, in the second I have removed the plugin from the folder so it doesn't load at all.  Both still have the same hand problem.  It is always after codeblocks trys to shutdown the pluggins and there are some wxYields thrown in there for good mix.



[attachment deleted by admin]

[MortenMacFly]

I was just wondering why Code::Blocks is going through all these changes after 2 release candidates.

I once had the same question (see http://forums.codeblocks.org/index.php?topic=1406.0). Meanwhile I think the changes are definitely worth it. There are drastic changes but even I am using a new build from time to time it just get's better. And that's what should be. So my worries are gone... but that's just me.
Morten.