Author Topic: Several show-stopping problems  (Read 20421 times)

ikolev

  • Guest
Several show-stopping problems
« on: March 11, 2006, 11:27:13 am »
Hi guys.

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).

I have two major projects that I work on in C::B. Both were imported from VC7.1 solutions. One is an open source library ( http://www.ikolev.com/DebugTools/ ) and consists just of two projects, one for the static library and one for the unit tests executable (which in C::B could be made targets, but I prefer the MS approach of a single project for each target, with several debug/release/etc. configurations). The other one is a large private project with several libraries (static and dynamic) and executables.

Here are the problems:

- 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.

- A non-fatal but quite unpleasant problem is the random change of project dependencies when loading a workspace. Unfortunately this happens only with the private project, so I can't post an example workspace. It also happens occasionally, it's not 100% reproducible. There are 9 projects in the workspace. Sometimes dependencies get so messed up, that when I hit Build for some project, C::B builds another one. Deleting all temporary build directories and the project .layout and .depend files and building from scratch fixes it.

- 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.
I can upload all source code and project files for DebugTools if required.

And in the end, a minor problem. In these projects I also have a "commands only" target called "RunTests" which is intended just to start the unit test executables. They contain built-in DOS commands like "cd" which won't work. I need to use "cmd /c cd ...", and of course this doesn't keep the current directory between commands, unless I use "cmd /c cd someDir & someExe & anotherExe".

Please let me know if I can do anything to help resolve the debugging problem in first place. I would have tried to debug C::B myself, but I cannot since debugging doesn't work :) 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++.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Several show-stopping problems
« Reply #1 on: March 11, 2006, 12:04:23 pm »
Quote
I download each new nightly build in hope that they may be fixed, but it seems they are not known

And they will remain unknown if noone reports them.

Quote
- First of all, of course, are the regular crashes.

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.

Once again, having never experienced it, I can't be of much help (yes, I do work with large workspaces). Your best bet is to create a minimal reproducible test-case and send it to us describing the steps to reproduce.

Quote
- The most important problem is the impossibility to debug from the IDE.

You can't debug anything, or your projects in question?

Quote
And in the end, a minor problem.

Why don't you create a batch file (say, runtests.bat) and call this from your commands-only target?

Quote
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 think that my earlier reply on a similar question should answer this.

For the end, I left your opening sentence that I 'd like to quote:

Quote
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)

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?

Yiannis.
Be patient!
This bug will be fixed soon...

Offline squizzz

  • Almost regular
  • **
  • Posts: 132
Re: Several show-stopping problems
« Reply #2 on: March 11, 2006, 06:54:25 pm »
Hi,

At some point (when I started using nightly builds, to be exact) I've experienced pretty much all of the problems you mention. The reasons of these problems were trivial, so let me shortly pinpoint them. Maybe it helps you solve yours.

- 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.
If that's your case, simply create new, separate directory and unpack nightly builds there. That solved all the oddities here.

Quote
- 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.
I can upload all source code and project files for DebugTools if required.
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 (check the bottom of the page, in snapshot section)

Hope that helps,
Jan
« Last Edit: March 11, 2006, 09:38:02 pm by squizzz »
this space is for rent

Offline RJP Computing

  • Almost regular
  • **
  • Posts: 135
    • RJP Computing
Re: Several show-stopping problems
« Reply #3 on: March 11, 2006, 09:15:27 pm »
First off, this IDE is the best IDE for GCC hands down. Way to go. I use it daily and it works well. Thanks for all your effort.

I agree with squizzz and ikolev. I had all kinds of weird crashes which seemed to be from me upgrading a RC2 install to the nightly builds. I also found that by changing away from the RC2 MinGW install it helped a lot. I still see periodic crashing when closing Code::Blocks when it has a large project open and it has been open for a long period of time. I have not tried to disable the code=completion plug-in yet. I use that ALL THE TIME. But I definitely could to see if it gave me more stability.

Once again thanks for all the updates and the great IDE.
- Ryan

Ubuntu/WinXP, AMD Athlon 64 3000+, 1000MB RAM, AC 97 Audio, ATI Radeon 9600XT 256MB

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Several show-stopping problems
« Reply #4 on: March 11, 2006, 09:55:40 pm »
Hello,

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).

Using a new IDE requires time and practice. If you have a problem with C::B, the best thing to do is first to have a look at the C::B wiki and do a search in the forum. If you find no info, then you can post your problem in the forum (without forgetting your C::B/OS version, which compiler do you use, etc.).

Personally, I find C::B much better than Dev-C++ and Eclipse, but this does not means that they are worthless. I have tried both and you can work with them more or less good, mostly depending on your application requirements.

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).

If you remark/experience problems, you should check in the forum and in BerliOS to see if they have been reported already. If not, you can post your bug in BerliOS.

Best wishes,
Michael

Offline Vampyre_Dark

  • Regular
  • ***
  • Posts: 255
  • Hello!
    • Somewhere Over The Rainbow...
Re: Several show-stopping problems
« Reply #5 on: March 12, 2006, 12:11:15 am »
You might like MinGW Studio, or MinGW Developper studio then, until code::blocks works for you.
C::B Wishlist
~BOYCOTT THE EVIL YELLOW BOXES~

ikolev

  • Guest
Re: Several show-stopping problems
« Reply #6 on: March 12, 2006, 12:53:04 pm »
Hi again.
OK, one by one.

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.

Thanks, I think I mixed the builds too. I unzipped rev2170 into a clean folder now.

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...

I hope these are caused by unzipping the nightly build on top of RC2.

Quote
- A non-fatal but quite unpleasant problem is the random change of project dependencies when loading a workspace.

Again, lets hope this is caused by the wrong installation.

Quote
- The most important problem is the impossibility to debug from the IDE.

You can't debug anything, or your projects in question?

I can debug a sample Hello World project. The (important) difference between it and my projects is that in mine I have project files in sub-folders, so the structure is like:
/proj_cb
/proj_vc71
/include
/src
All file references in the C::B project start with ../include/ or ../src/ . It seems this is the problem with GDB. I did the same for the sample project - moved the .cbp file into a sub-folder, like this:

F:\w\w\CBTest\main.cpp
F:\w\w\CBTest\proj_cb\CBTest.cbp
F:\w\w\CBTest\proj_cb\CBTest.depend
F:\w\w\CBTest\proj_cb\CBTest.exe
F:\w\w\CBTest\proj_cb\CBTest.layout
F:\w\w\CBTest\proj_cb\.objs
F:\w\w\CBTest\proj_cb\.objs\main.o

And breakpoints stopped working. This is the debugger log when I place a breakpoint at line 10 in main.cpp and hit F8:

Selecting target: default
Compiling: done
Adding source dir: F:\w\w\CBTest\proj_cb\
Adding file: CBTest.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.3
No source file named F:/w/w/CBTest/main.cpp.
Breakpoint 1 (F:/w/w/CBTest/main.cpp:10) pending.
Program exited normally.
Debugger finished with status 0


On one hand, the line "Adding source dir: F:\w\w\CBTest\proj_cb\" hints that C::B adds the wrong source dir to GDB. On the other, 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*.

Why don't you create a batch file (say, runtests.bat) and call this from your commands-only target?

This is indeed a good idea, not because it's a workaround, but because this way post-build actions will be grouped together in one place and can be shared between different build scripts and IDE's. Still, I don't see why C::B should not allow usage of built-in DOS commands and maintain state (like current directory) between them. Though it may be a bad idea, I don't know... maybe I'm spoiled by VC :)

Quote
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 think that my earlier reply on a similar question should answer this.

Oh well, I should have searched the forum about this. I may post my opinion in that thread.

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 (which feels like returning 15 years in the past... though even then we had Turbo Debugger :) )

I see that the other posters have also misunderstood my mentioning of Dev-Cpp... Please don't get me wrong, I'm not criticizing C::B or trying to compare it to Dev-Cpp - the first would be ungrateful (when getting C::B for free) and the second is pointless. Maybe I'm too enthusiastic about C::B (I think it's a dream come true, as I noted in my first post) and take any flaws with extra emotion. I just felt pity that having such a good IDE I would be forced to switch to a much worse one, which however could get the job done, though with much more effort.

As for the GDB version and checking the forum and the bug database - sure, I've done all that. In general, I hate complaining, so I always do a thourough research before posting problems on forums. Also, I don't like littering bug databases with bugs which turn out to be my own mistakes, so I prefer to discuss the problem before filing a bug report.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Several show-stopping problems
« Reply #7 on: March 12, 2006, 01:10:26 pm »
Quote
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)

I've been following this thread for a while and could not help but smile :)
You should know that Yiannis (mandrav) knows what Dev-CPP can and cannot do better than probably anybody else here. :lol:

But seriously, debugging works really good with Code::Blocks if you have set up everything correctly, way better than it ever did with Dev-Cpp. I know because I have used Dev-CPP for years, and I (obviously :)) use Code::Blocks every day now (including the debugger). Also, I rarely ever see an application crash (Code::Blocks runs about 12-14 hours daily on my machine). When using Dev-CPP, one crash per hour was what I considered normal.

I too had problems getting the debugger to work initially, a few months ago, but it was purely my fault (did not set up gdb correctly).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Several show-stopping problems
« Reply #8 on: March 12, 2006, 01:26:45 pm »
ikolev: The best you can do is post each issue here or at the bug tracker, and when possible try to minimize each problem found to the smallest reproductable test case possible. High chances are that it will be fixed in few hours, if not, patches or more input are appreciated. :)

ikolev

  • Guest
Re: Several show-stopping problems
« Reply #9 on: March 12, 2006, 02:19:11 pm »
... 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.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Several show-stopping problems
« Reply #10 on: March 12, 2006, 09:04:56 pm »
... 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.

Hello,

If I remember correctly, I have had this problems one or two times, until I discovered that I have forgotten to add the compiler flag -g. After, I added it, GDB worked fine :).

Best wishes,
Michael

ikolev

  • Guest
Re: Several show-stopping problems
« Reply #11 on: March 13, 2006, 09:12:24 am »
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
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). Anyway, I think that's not needed since the example is quite easy to set up - just the standard hello.cpp and a Hello.cbp file in a sub-folder below it.

For now I can avoid the problem by copying the .cbp files into the project root folder, after manually removing the leading ../ in the paths to the headers/sources inside the .cbp file.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Several show-stopping problems
« Reply #12 on: March 13, 2006, 10:35:54 am »
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).

You get this error even if you try to attach file(s) to a post. You might would like to look at here.

Best wishes,
Michael

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Several show-stopping problems
« Reply #13 on: March 13, 2006, 10:51:13 am »
Quote
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

Bug fixed, thanks for spotting it :)
Be patient!
This bug will be fixed soon...

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Several show-stopping problems
« Reply #14 on: March 13, 2006, 02:44:46 pm »
Quote
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
Bug fixed, thanks for spotting it :)
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:
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
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline klight

  • Multiple posting newcomer
  • *
  • Posts: 24
Re: Several show-stopping problems
« Reply #15 on: March 13, 2006, 03:32:59 pm »
I can also confirm it's fixed.
Thank you!

ikolev

  • Guest
Re: Several show-stopping problems
« Reply #16 on: March 13, 2006, 09:33:17 pm »
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.

takeshimiya

  • Guest
Re: Several show-stopping problems
« Reply #17 on: March 13, 2006, 09:51:46 pm »
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.

What would be good to understand is why the crashes.
The configuration can't be, as it was saved in the registry.
The old lexers/resources/etc shouldn't crash C::B, because they hadn't changed much, and all the code is backwards compatible.

The only thing that could produce the crash would be old shared libraries.

Like old plugins with different name or not in new versions (as the svn plugin).
But if that's the case, loading plugins made for a previous SDK shouldn't load, as they are versioned.

The other cause could be that the wxWidgets dll shipped with RC2 was another version (2.6.1?).
But if that's the case, we should start building wxWidgets as wxmsw262u instead of wxmsw26u.
Or another option could be to check upon C::B load at runtime, if the main app and plugins were compiled against the same configuration&version of wxWidgets dll.

So, what could be the problem?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Several show-stopping problems
« Reply #18 on: March 13, 2006, 10:57:56 pm »
Quote
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.
Quote
The only thing that could produce the crash would be old shared libraries.
Like old plugins with different name or not in new versions (as the svn plugin).
No, Takeshi.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Several show-stopping problems
« Reply #19 on: March 13, 2006, 11:19:50 pm »
Quote
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.

It is spotted which are exactly?
I don't understand which one could be, as most resources are loaded from the zips, and all those are overwritten by new versions because they have the same name. And the lexers have the same name too.

Doing a diff of all files between RC2 and HEAD, gives the next sensible files missing in HEAD:

CodeBlocks/share/CodeBlocks/plugins/cbDragScroll.dll
CodeBlocks/share/CodeBlocks/plugins/FileTabMenu.dll
CodeBlocks/share/CodeBlocks/plugins/svn.dll
CodeBlocks/share/CodeBlocks/svn.zip
CodeBlocks/mingwm10.dll
CodeBlocks/wxmsw26_gcc_cb.dll


So those are the ones that could introduce a problem, the rest are overwritten by same-name files.

That is, unless ikolev had click "don't overwrite files" when uncompressing Nighlty over RC2.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Several show-stopping problems
« Reply #20 on: March 13, 2006, 11:47:19 pm »
There are (at least) two things which may cause a crash. The plugins are certainly not among them. Plugins are checked for their SDK version before anything is initialised.

The first thing that will crash is either dereferencing a pointer obtained by XRCCTRL just before the first dialog shows or while the main menu bar is being created, whichever happens first.
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).

It is, however, quite counter-productive to discuss this. It only encourages people to actually try and do it, which they should not. We have enough things to deal with already, no need to invent new complications by mixing versions.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Several show-stopping problems
« Reply #21 on: March 14, 2006, 12:35:18 am »
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.
I've experienced (not on purpose) a strange crash where I couldn't understand what was happening, or why was C::B crashing.
It costed me 2 days, until I opened a plugin with a dependecy scanner, and noticed that it was trying to use a non-unicode wxWidgets symbols, whereas I had a unicode wxWidgets dll.
But the point is that it let me go that far away, and those kind of problems aren't rare.

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.
I want to know what are the reasons, and then fix it if possible, by any means.

As ikolev demostrated, it is a serious problem, and he is not the first to have it.

The ways that could solve it are:

*Putting on first run, a messagebox warning "don't mix versions". (not good)
*Checking if the wxWidgets dll configuration is the same as the plugins/program, at runtime.


Again, mixing versions isn't bad generally, in other programs. Indeed, an example is Firefox.
A recommended way to upgrade is to put new versions over the older versions.
What they clarify, it's to never mix the profile folder of different versions (in C::B the equivalent would be mix the configuration files).

Also, keep in mind that in the future C::B could update itself, just like Dev-C++ did.
I even recall Yiannis saying it at some time.

So if we don't solve the problem now, we will keep getting more reports of this kind.  :(

ikolev

  • Guest
Re: Several show-stopping problems
« Reply #22 on: March 14, 2006, 10:53:38 am »
That is, unless ikolev had click "don't overwrite files" when uncompressing Nighlty over RC2.

I surely haven't done that (what's the point to _update_ an existing installation without overwriting files with the new ones?)

I tend to agree that these problems are better sorted out if C::B plans to be regularly updated, and especially if it plans to support mixed version plugins (i.e. plugins written for previous or later versions of C::B).

I want to remind about the other problem (not just the crashes) which can give some clues - the messed up project dependencies after loading a workspace. Generally, what happened was that one of the projects was automatically set as a dependency for all others.

And I can also give you the .rpt file which I kept, hoping that it can be of help - http://www.ikolev.com/files/codeblocks.rpt.zip

Regards,
Ivan

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Several show-stopping problems
« Reply #23 on: March 14, 2006, 12:38:54 pm »
http://www.ikolev.com/files/codeblocks.rpt.zip
Well, the file shows that the source for many crashes is cbProject::SaveAllFiles. The code of this method looks like that:
Code
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;
}
What could not work here? the ProjectFile could be NULL, Manager::Get()->GetEditorManager() could return NULL. You could easily add such verification yourself and help us to discover what's happening. 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!
With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

takeshimiya

  • Guest
Re: Several show-stopping problems
« Reply #24 on: March 14, 2006, 05:22:24 pm »
From the call stack here are the functions causing trouble (the most frequent is the wxListBase::GetCount() one):

1) sdk/workspaceloader.cpp
WorkspaceLoader::Save(wxString const&, wxString const&)
cbWorkspace::Save(bool)
ProjectManager::SaveWorkspace()

2) sdk/messagemanager.cpp
MessageManager::DebugLogError(wchar_t const*, ...)
ProjectManager::DoOpenFile(ProjectFile*, wxString const&)
ProjectManager::DoOpenSelectedFile()
ProjectManager::OnProjectFileActivated(wxTreeEvent&)

3) sdk/cbworkspace.cpp
cbWorkspace::Save(bool)
ProjectManager::SaveWorkspace()
ProjectManager::QueryCloseWorkspace()
ProjectManager::CloseWorkspace()

4) sdk/cbproject.cpp
wxListBase::GetCount() const [sdk]
cbProject::SaveAllFiles() [sdk]
PluginSDKVersion [compilergcc]

5) sdk/cbproject.cpp
wxNodeBase::GetData() const [sdk]
wxFilesListNode::GetData() const [sdk]
cbProject::SaveAllFiles() [sdk]
PluginSDKVersion [compilergcc]


ikolev

  • Guest
Re: Several show-stopping problems
« Reply #25 on: March 14, 2006, 05:48:01 pm »
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!

Note that this happens only with a "crippled" installation, i.e. unzipping a nightly build on top of an RC2 install. I don't get these crashes with cleanly installed nightly builds. (BTW, now I'm unzipping each new nightly build on top of the previous ones, so such problems *might* appear again - we'll see.)
I think CB developers should not waste time chasing such problems, at least for now... I don't have much time myself. I thought that the .rpt file might be enough to find the problem, but if it isn't, better not waste further efforts on this. If you insist though, I have saved the crippled installation and can do some debugging, or hand it over to someone who has more time :)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Several show-stopping problems
« Reply #26 on: March 14, 2006, 05:58:02 pm »
The reason for the crashes in your rpt file have been recently fixed (just a couple of days ago).
Be patient!
This bug will be fixed soon...