Run Button in C::B different than Running From OS

[Sqeaky]

I am aware of a few of the differences of running an application from inside an IDE vs double clicking on the executable, things like the working directory and information that is passed to the application about where to find dynamic libraries (.DLLs and .SOs). However, I am getting some really odd behavior when I run an application I am working on from inside Code::Blocks

When I try to run it from the OS I double click it and the OS asks me what to do to Run it or Display it (I am using ubuntu 10.10 64 bit, but I get similar behavior on 10.04 32 bit and 10.04 64 bit). I click run it just works, it also works fine from the command line. However it doesn't work when I try to run it using the run button in Code::Blocks, but it used to work fine a few months ago. Now, it runs into the early parts of the application initialization and simply pauses execution. Whenever I run into this issue it seems to pause in the same place unless I make a major change to my applications code, then the place it pauses at moves to another seemingly random place. It also pauses in different locations based on whether I am debugging or simply running the program, and which computer I am working on. I can tell exactly where it pauses because my application logs a lot of data and I can find the log messages in the code and tell where it stopped logging. When I am debugging I can tell it has paused because the Debugger will simply not let me advance to the next line. Once an application has paused this way clicking the "abort" button does nothing. The only way to convince Code::Blocks that the application is not running is to close it and re-open Code::Blocks.

I have tried the versions: 8.02, 10.05. SVN 6205 (I think), and I am using SVN 6703 it doesn't seem to affect it in any meaningful way. Currently the windows version of the application runs fine. I searched for other similar bugs and I couldn't find any, nor could I determine what in my application was causing this issue (assuming it was something in my application).

Any ideas? Any at all? What information would be helpful to aid troubleshooting?

[oBFusCATed]

For better debugging support, try CB from the debuggers branch (wxpropgrid_debugger)...

I'm not sure if I've understand the problem correctly...
Does your application works from the command line as expected?
If not you can debug it the hardcore way with pure gdb (or another debugger wrapper ddd, kdbg).

[Sqeaky]

My application works fine from the command line. Even if I use a tool like gbd or valgrind.

But it fails to run from inside C::B. It simply fails to advance past a certain point when I click the run button (The green ">" Arrow), and it simply fails to advance past a different bit still certain point when I am debugging inside C::B.

Each time I run it under a given set of conditions inside code::blocks it always pauses in the same place. If I change the conditions, like the OS, or whether or not I am debugging, it pauses at some new place until I change the conditions again.

I will look into the developers branch. I think I will avoid being hardcore for the time being, I would rather determine if it some odd bug with my application, an an odd bug in Code:Blocks, or something else that can be fixed.

Edit: I described more about my problem.

[oBFusCATed]

Hm, pretty strange...

Have you tried to see if the working dir of your app is the same to the one from the console.
Does you app depend on the environment?
If it does verify that the environment is the same both times (use the env parameter of main() ).

And also does simple hello world app works as expected?

[Sqeaky]

Simple hello world app in the same workspace as my application (which is split into 3 projects) works.

My app indirectly uses the environment. It uses the LD_LIBRARY_PATH to know where to search for external libaries. (It uses like 10 or more shared libraries, it is ridiculous).

I will check the env for that right now. But I would expect it to simply crash with SigTerm or SigAbrt if it couldn't find a required library.

gimme 10 minutes and I will check.

[Sqeaky]

I sent the "LD_LIBRARY_PATH:" and then etenv("LD_LIBRARY_PATH") to the logger. The logger handles multi-threading issues, adds a time stamp then adds one line to log file with the requested data. It was about 3:00pm local time when I ran this hence the 15:00:XX

From the OS command line:
dev@dev-laptop:~$ echo $LD_LIBRARY_PATH

dev@dev-laptop:~$
Nothing, just a blank line

When run from the OS I get this in the log file:
15:00:43: LD_LIBRARY_PATH:
15:00:43: .:

When running from Code::Blocks using run button, I get this in the log file:
15:04:14: LD_LIBRARY_PATH:
15:04:14: .:/home/dev/physgame/EngineDemo/bin/LinuxDebug:/home/dev/physgame/EngineDemo/.:

When running from Code::Blocks using Debug button it didn't get to the main of application where we could use getenv at. So I changed where I was doing the logging to be closer to the beginning of execution and I got this result I get in the log file:
15:13:14: LD_LIBRARY_PATH:
15:13:14: .:/home/dev/physgame/EngineDemo/bin/LinuxDebug:/home/dev/physgame/EngineDemo/.:

So there is a difference but is it significant? Could having extra search directories in the path cause a problem?


Edit: I more clearly described where I found each result.

[Sqeaky]

Sorry for the triple post, but the content really doesn't seem to belong in the same post.

For reference the application I am working on is 3d game and game library. It is split up into 3 Code::Blocks projects. "Physgame" is the library, "EngineDemo" is a unit test and place try all the features of Physgame, and "Catch!" is the actual game. Right now I am working in the EngineDemo to test some new functionality we just added to Physgame. EngineDemo and Catch! both link to Physgame and not much else, and Physgame links to several external libraries and provides a single interface to the required functionality of Ogre3d, bullet3d, ticpp/tinyxml, Boost, SDL and certain OS dependent functionality.

Currently Physgame is single threaded, but Ogre3d and Bullet both spawn separate threads to perform some of all of the work they do. These are both well tested, and the issue I am having has existed before and after having changed library version. For example When we moved from Ogre 1.7.0 to 1.7.1 the issue still existed, it would simply pause somewhere else.

I would also like to note that sometimes, the issues simply does not occur. After certain major code changes the run and debug buttons would work, other times only one or the other would work. Right now neither work. When using the Debugger is pauses when I am initializing the Logger, sometimes after Ogre has finished it's initialization and sometimes not. When using the run button currently it is pausing just after the window and 3d rendering canvas are displayed, but before anything is rendered.

Edit: While writing this it occurred to me that this could be some kind of Race condition that the extra overhead of having and IDE could cause. I thought maybe physgame is trying to call on Ogre or Bullet Components before that have finished initialising. I tested this by putting a 1.5 second delay in between initializing Ogre and when it is first called, and it still crashes in the exact same place when both debugging and running it. I will try playing with LD_LIBRARY_PATH next.

[Sqeaky]

This has been resolved. I have been able to debug in CodeBlocks consistently for about the past week.

Two relevant things have changed since I last attempted this. Our project now uses cmake to create build files (which I sometimes use to make Code::Blocks files). Right now I am using version SVN 6862. I don't know which one fixed the issue.