I download each new nightly build in hope that they may be fixed, but it seems they are not known
- First of all, of course, are the regular crashes.
- A non-fatal but quite unpleasant problem is the random change of project dependencies when loading a workspace.
- The most important problem is the impossibility to debug from the IDE.
And in the end, a minor problem.
I considered porting the C::B project files to Visual C++ so I can debug it there (besides, the VS debugger is very, very good), but I found that it would require a lot of source code changes. If there is interest in this, I could spend some time porting C::B to Visual C++.
I have a few serious problems with Code::Blocks, which are about to make me look for another GCC-based development environment for Windows (Dev-Cpp seems the only choice, Eclipse is tragic).(emphasis added by me)
- First of all, of course, are the regular crashes. They happen mostly when switching projects/workspaces. Sometimes the new workspace is loaded successfully, but a crash occurrs when hitting Build (Ctrl-F9). I can upload the .rpt file if that can help.It happened to me because I mixed RC2 version with nightly build (I unzipped nightly build to RC2 directory). It was not only randomly crashing, but many options were working in a weird way.
- The most important problem is the impossibility to debug from the IDE. I have set all needed options (compiler debug info etc.), and I am able to debug with gdb from the command line. However, that's quite unproductive. I think the problem is (almost) the same as described by klight in this thread http://forums.codeblocks.org/index.php?topic=2509.0 . Any breakpoints I set are listed as "pending" by gdb and never resolved. Also, I cannot single-step in the source code. With the larger project the executable doesn't even start, it just hangs. With DebugTools at least the program starts and finishes successfully, but I cannot debug it.Make sure you use GDB at version 6.3. Got the same behaviour unless I upgraded it. Because GDB 6.3 is at RC stage, there is fair probability that you don't have it yet. You may get it here (http://mingw.org/download.shtml) (check the bottom of the page, in snapshot section)
I can upload all source code and project files for DebugTools if required.
I have a few serious problems with Code::Blocks, which are about to make me look for another GCC-based development environment for Windows (Dev-Cpp seems the only choice, Eclipse is tragic).
I download each new nightly build in hope that they may be fixed, but it seems they are not known, so I decided to post here (I can also post bug reports on the BerliOS if required).
It happened to me because I mixed RC2 version with nightly build (I unzipped nightly build to RC2 directory). It was not only randomly crashing, but many options were working in a weird way.
If that's your case, simply create new, separate directory and unpack nightly builds there. That solved all the oddities here.
Regular crashes... Hmm... I can't give you much help since I seldomly experience any crashes here (in three PCs, two win32 one linux64) and if I do I almost immediately fix it and commit.
Try disabling the code-completion plugin. It's the only known source of crashes...
Quote- A non-fatal but quite unpleasant problem is the random change of project dependencies when loading a workspace.
Quote- The most important problem is the impossibility to debug from the IDE.
You can't debug anything, or your projects in question?
Why don't you create a batch file (say, runtests.bat) and call this from your commands-only target?
QuoteI considered porting the C::B project files to Visual C++ so I can debug it there (besides, the VS debugger is very, very good), but I found that it would require a lot of source code changes. If there is interest in this, I could spend some time porting C::B to Visual C++.
I think that my earlier reply (http://forums.codeblocks.org/index.php?topic=2437.msg19230#msg19230) on a similar question should answer this.
I 'm really confused by this very sentence...
Dev-Cpp is a nice little IDE (windows-only, gcc-only) which is good for small scale projects.
But you got me confused here: you 're talking about problems with C::B regarding large workspaces with multiple targets per-project, inter-project dependencies on a workspace level and whatnot.
Newsflash:
Dev-Cpp does not support any of these features.
So, what is exactly the point you 're trying to make with this sentence?
No point other than the fact that Dev-Cpp can debug from the IDE. I know what it can and cannot do, and I realized it was *possible* (though not easy) to create a set of Dev-Cpp projects and do my job without having to debug with gdb from the command line(emphasis added)
... the line "No source file named F:/w/w/CBTest/main.cpp" sounds quite strange, since the full path to main.cpp is *exactly this*.
... the line "No source file named F:/w/w/CBTest/main.cpp" sounds quite strange, since the full path to main.cpp is *exactly this*.
I just remembered from other discussions on the forum that GDB *always* displays the message "No source file..." before a pending breakpoint, even when the source file is there, so this is not "strange" - it's normal.
Since the bug tracker doesn't allow attaching files, I tried to attach the simple example workspace here, but I got an error "the uploader folder is full" (the file size is 1 KB).
No, it's not missing options - I already explained the cause of the problem above. I filed a bug report about it here http://developer.berlios.de/bugs/?func=detailbug&bug_id=6756&group_id=5358
Oh man, that was something driving me mad for a while now. I'm glad it's fixed (and I can confirm that it works now). I realised the same issue that the debugger wasn't working for a project of mine but since it was working for all the others I thought it's my fault. I can only underline the following statement of mandrav:QuoteNo, it's not missing options - I already explained the cause of the problem above. I filed a bug report about it here http://developer.berlios.de/bugs/?func=detailbug&bug_id=6756&group_id=5358Bug fixed, thanks for spotting it :)
And they will remain unknown if noone reports them....and by the way: This thread once again shows very nicely a fact that "ships" with C::B: If there is a bug discovered and identified it's fixed nearly immediatley. I don't know any other software that reacts so fast. That alone would be reason enough to use C::B... :P
Big thanks from me too. It's working now.
Another good news is that C::B has not crashed on me yet since I installed the nightly build in a clean folder. I guess this is worth mentioning somewhere (e.g. in some instructions for installing the nightly builds). Unless it is mentioned and I have missed it.
The old lexers/resources/etc shouldn't crash C::B, because they hadn't changed much, and all the code is backwards compatible.As it happens, those are the likely reason.
The only thing that could produce the crash would be old shared libraries.No, Takeshi.
Like old plugins with different name or not in new versions (as the svn plugin).
QuoteThe old lexers/resources/etc shouldn't crash C::B, because they hadn't changed much, and all the code is backwards compatible.As it happens, those are the likely reason.
The second thing that will crash is wxDialog::ShowModal because of a version conflict in the two wxWidgets libraries (but you never get that far, anyway).Actually, I think that's the most probable reason.
It is, however, quite counter-productive to discuss this.No, it isn't. Not discussing problems is not good, more when it can be solved.
That is, unless ikolev had click "don't overwrite files" when uncompressing Nighlty over RC2.
http://www.ikolev.com/files/codeblocks.rpt.zipWell, the file shows that the source for many crashes is cbProject::SaveAllFiles. The code of this method looks like that:
bool cbProject::SaveAllFiles()
{
int count = m_Files.GetCount();
FilesList::Node* node = m_Files.GetFirst();
while(node)
{
ProjectFile* f = node->GetData();
if (Manager::Get()->GetEditorManager()->Save(f->file.GetFullPath()))
--count;
node = node->GetNext();
}
return count == 0;
}
I use C::B daily with large projects and workspaces (around 1500 files and workspaces with around 40 projects). This never happens to me so it is really difficult to verify. It's OpenSource so you really could help - please!