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

Offline Ivan Kolev

  • Multiple posting newcomer
  • *
  • Posts: 20
    • Home page
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: 4291
    • 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~

Offline Ivan Kolev

  • Multiple posting newcomer
  • *
  • Posts: 20
    • Home page
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."

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
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. :)

Offline Ivan Kolev

  • Multiple posting newcomer
  • *
  • Posts: 20
    • Home page
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

Offline Ivan Kolev

  • Multiple posting newcomer
  • *
  • Posts: 20
    • Home page
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: 4291
    • 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: 9508
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: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ