Author Topic: Exectution Directory and Debbuger Working Directory  (Read 25977 times)

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Exectution Directory and Debbuger Working Directory
« on: February 27, 2012, 01:43:49 am »
Hi,

I'm sorry if this question has been asked a thousand times already, but googling and search on the forum and on the wiki didn't gave result (maybe I didn't searched the right way ?)


My problem : I made a small program accessing files by relative path. When I run debug or release target from Code::Blocks, it works, files are found and parsed. The same when I directly run the .exe. But when I debug (Debug->Start) the very same program, the files aren't found.

My configuration : Windows using Codeblocks with Mingw/gcc compiler. The exe files are output in "ProjectName/bin" directory. There is no space in path.

What I tried :
- I tried changing the Execution Directory, with no change in behaviour.
- Adding the file that is not found while using the debugger some other place. When I put it in "ProjectName" directory, it is still not found, but if I place it in the parent directory of "ProjectName", it works (though it is not even in the workspace).
- When I launch my exe file through the "cmd" tool, the path from where I launch it doesn't matter : it always works.

Any help would be appreciated ! :)
(even pointing the good keywords to find the solution)

Thanks !

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5916
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Exectution Directory and Debbuger Working Directory
« Reply #1 on: February 27, 2012, 02:11:06 am »
My configuration : Windows using Codeblocks with Mingw/gcc compiler. The exe files are output in "ProjectName/bin" directory. There is no space in path.
What I tried :
- I tried changing the Execution Directory, with no change in behaviour.
- Adding the file that is not found while using the debugger some other place. When I put it in "ProjectName" directory, it is still not found, but if I place it in the parent directory of "ProjectName", it works (though it is not even in the workspace).
- When I launch my exe file through the "cmd" tool, the path from where I launch it doesn't matter : it always works.
Change you "execution working dir" to "ProjectName/bin" should solve your problem, because this will have the same working dir as you launch your exe in the command shell (suppose you first cd to "ProjectName/bin", and type the app name to run it). Both the debugger and the console runner use the same "execution working dir".

If it still does not works, more details should be told about your project. (like the log message you "Run" your app, and the log message you "Debug" your app)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Re: Exectution Directory and Debbuger Working Directory
« Reply #2 on: February 27, 2012, 12:20:48 pm »
Hi Ollydbg,

Thanks for your answer :)

By "execution working dir", Do you mean "Project settings">"Execution directory" ?
If yes, then it does not solve the problem. :(

If using the console, I "cd" to "ProjectName/.." and then "ProjectName/bin/ProjectName.exe", the program runs without error. If I cd to "ProjectName/bin/" and then "ProejctName.exe", it works as well. Though, I don't know if windows makes a difference in this case. Maybe both ways he runs the program in its own directory (with an implicit cd ?).

When running my app, I don't have any special log. Files are found and processed. No error.
When launching it by "Debug">"Start", the error is "no such file or directory".

I'm using Code::Blocks 10.05 (installed with MinGW, but I switched to a newer version of minGW since then). It is a console application.
My program runs on orx engine and it is the configuration file loading that fails (only when debbuging and if I don't place the config file in the parent directory of my project "ProjectName/..").

I thought it might be a directory separator problem, like using "/" unix style instead of "\\" windows style, but the fact it works when run and it doesn't when debbuged puzzles me.

I'll give more information in a few hours when I'm home (Build logs, project configuration file, if you see anything else that could be helpfull...).

Thanks ! :)
« Last Edit: February 27, 2012, 12:22:29 pm by le Pape »

Offline p2rkw

  • Almost regular
  • **
  • Posts: 142
Re: Exectution Directory and Debbuger Working Directory
« Reply #3 on: February 27, 2012, 07:18:43 pm »
Check process working directory while running with and without debugger, for example with 'system("cd");'. Are both of these absolute paths are same?

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Re: Exectution Directory and Debbuger Working Directory
« Reply #4 on: February 27, 2012, 11:38:41 pm »
Hello p2rkw,

Thanks for your tip !

I tried it and the result is interesting but kinda puzzling for me :
I placed a system("cd"); at the beginning of the main function and another at the end.

In both case (run or debugging), the first gives the correct result : Parent/ProjectName/bin
But the second system("cd");, run at the end, gives "Parent/ProjectName/bin" when I run the program but "Parent" when I debug it.

In other words, when I run it, everything is ok, but when I debug it, the first is ok, the second is wrong.

Maybe it is a problem in the code I use, though, I can't see how the behavior can differ from runing with debugging. I though it was the very same assembly ?



Here is the build log :
Code
-------------- Build: Debug in ProjectName ---------------

Compiling: src\ProjectTest.cpp
lib\orx-1.3rc0\include/utils/orxString.h:276:41: warning: 'orxU32 orxString_PrintUTF8Character(orxCHAR*, orxU32, orxU32)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:391:35: warning: 'orxCOLOR* orxColor_FromRGBToHSL(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:468:35: warning: 'orxCOLOR* orxColor_FromHSLToRGB(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:562:35: warning: 'orxCOLOR* orxColor_FromRGBToHSV(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:637:35: warning: 'orxCOLOR* orxColor_FromHSVToRGB(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
Compiling: main.cpp
lib\orx-1.3rc0\include/utils/orxString.h:276:41: warning: 'orxU32 orxString_PrintUTF8Character(orxCHAR*, orxU32, orxU32)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:391:35: warning: 'orxCOLOR* orxColor_FromRGBToHSL(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:468:35: warning: 'orxCOLOR* orxColor_FromHSLToRGB(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:562:35: warning: 'orxCOLOR* orxColor_FromRGBToHSV(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
lib\orx-1.3rc0\include/display/orxDisplay.h:637:35: warning: 'orxCOLOR* orxColor_FromHSVToRGB(orxCOLOR*, const orxCOLOR*)' defined but not used [-Wunused-function]
Linking console executable: bin\ProjectNameD.exe
Output size is 5.24 MB
Process terminated with status 0 (0 minutes, 7 seconds)
0 errors, 10 warnings


Well, my path kinda look like people waving both arms \o/ and the compiler seems to be a little too careful regarding libraries (yes, some functions are declared but not used, easy compiler, easy, it's gonna be okay), but nothing too bad I think.


The project config file :

Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
<FileVersion major="1" minor="6" />
<Project>
<Option title="ProjectName" />
<Option pch_mode="2" />
<Option compiler="gcc" />
<Build>
<Target title="Debug">
<Option output="bin\ProjectNameD" prefix_auto="1" extension_auto="1" />
<Option working_dir="bin" />
<Option object_output="obj\Debug\" />
<Option type="1" />
<Option compiler="gcc" />
<Compiler>
<Add option="-g" />
<Add option="-D__orxDEBUG__" />
</Compiler>
<Linker>
<Add library="lib\orx-1.3rc0\lib\static\liborxed.a" />
<Add library="lib\extern\SOIL\lib\mingw\libSOIL.a" />
<Add library="lib\extern\openal-soft\lib\mingw\libopenal32.a" />
<Add library="lib\extern\freetype-2.4.1\lib\mingw\libfreetype.a" />
<Add library="lib\extern\libsndfile-1.0.22\lib\mingw\libsndfile.a" />
<Add library="lib\extern\SDL-1.2.14\lib\mingw\libSDL.a" />
<Add library="lib\extern\Box2D_2.1.3\lib\mingw\libbox2dd.a" />
<Add library="lib\extern\glfw-2.7\lib\win32\libglfw.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-system-d.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-audio-d.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-graphics-d.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-network-d.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-window-d.a" />
<Add library="OpenGL32" />
</Linker>
</Target>
<Target title="Release">
<Option output="bin\ProjectName" prefix_auto="1" extension_auto="1" />
<Option working_dir="bin" />
<Option object_output="obj\Release\" />
<Option type="1" />
<Option compiler="gcc" />
<Compiler>
<Add option="-O2" />
</Compiler>
<Linker>
<Add option="-s" />
<Add library="lib\orx-1.3rc0\lib\static\liborxe.a" />
<Add library="lib\extern\SOIL\lib\mingw\libSOIL.a" />
<Add library="lib\extern\openal-soft\lib\mingw\libopenal32.a" />
<Add library="lib\extern\freetype-2.4.1\lib\mingw\libfreetype.a" />
<Add library="lib\extern\libsndfile-1.0.22\lib\mingw\libsndfile.a" />
<Add library="lib\extern\SDL-1.2.14\lib\mingw\libSDL.a" />
<Add library="lib\extern\Box2D_2.1.3\lib\mingw\libbox2d.a" />
<Add library="lib\extern\glfw-2.7\lib\win32\libglfw.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-system.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-audio.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-graphics.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-network.a" />
<Add library="lib\extern\SFML-1.5\lib\mingw\libsfml-window.a" />
<Add library="OpenGL32" />
</Linker>
</Target>
</Build>
<Compiler>
<Add option="-Wall" />
<Add option="-fexceptions" />
<Add option="-static-libgcc" />
<Add option="-D__orxSTATIC__" />
<Add directory="include" />
<Add directory="lib\orx-1.3rc0\include" />
</Compiler>
<Linker>
<Add directory="lib\orx-1.3rc0\dev-mingw\bin" />
</Linker>
<Unit filename="include\ProjectTest.h" />
<Unit filename="main.cpp" />
<Unit filename="src\ProjectTest.cpp" />
<Extensions>
<code_completion />
<debugger />
</Extensions>
</Project>
</CodeBlocks_project_file>

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Re: Exectution Directory and Debbuger Working Directory
« Reply #5 on: February 28, 2012, 11:47:59 am »
Okay, I think I've found the origin of the problem. Though, I don't know how to correct it (otherwise than by a dirty workaround) or if it is a bug ?

I printed argv[0], that was used someplace in the code and there was a difference between "run" and "debug" :

While runing : "C:\Some\Path\To\My\Project\ProjectName\bin\ProjectNameD.exe"
While debugging : "C:\Some\Path\To\My\Project\ProjectName/bin/ProjectNameD.exe"
That \o/ syndrome...

Do you know where I could configure Code::Blocks to have it debugging with "C:\Some\Path\To\My\Project\ProjectName\bin\ProjectNameD.exe" ?
I saw there was a way to force forward slash / with the tools, but it won't help.  :-\

I still can programmatically reformat the input string if needed, but it would be an awfull workaround...  ;D

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Exectution Directory and Debbuger Working Directory
« Reply #6 on: February 28, 2012, 11:57:28 am »
The native API folder delimiter is '/', the sooner you switch to it the better :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Re: Exectution Directory and Debbuger Working Directory
« Reply #7 on: February 28, 2012, 12:13:11 pm »
Hi oBFusCATed :)

Thanks for your advice, but...

I'm sorry, I don't get it.
How do I switch ?

For example, when I right-click on my project and open the "Project Settings", in the Filename field, I have : "C:\Some\Path\To\My\Project\ProjectName\ProjectName.cbp"
How do I tell Code::Blocks to change this with forward slashes ?

As I don't use a custom Makefile, the path to the Makefile (Execution Directory) is grayed and given with backslashes.

And more importantly : how do I tell the debugger and/or the runner to pass first argument to the main function with forward slashes instead of backslashes in the path ?


I'm working on Windows... I thought that with Seven there was some improvement in the tolerance of the '/' but that the default delimiter still was '\\' ?

Any clue on how to switch ? (I must have googled with the wrong keywords  :-\ )

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Exectution Directory and Debbuger Working Directory
« Reply #8 on: February 28, 2012, 12:28:35 pm »
The low level apis use the '/' or at least have no problem with them.
So my advice was to convert all '\' to '/' at the beginning of your program and be done with it.
You can go the alternative way also -> convert all '/' characters to '\'.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Re: Exectution Directory and Debbuger Working Directory
« Reply #9 on: February 28, 2012, 01:52:52 pm »
But there is neither '\' nor '/' at the beginning of my program... ???

I can summarize my problem to this :

Code
//========Main.cpp=========

#include <iostream>

using namespace std;

int main( int argc, char** argv )
{
    cout << argv[0] << endl;
    return 0;
}


Project parameters : default
compiler : GNU GCC (MinGW)


Run Output :

Code
C:\Path\To\That\Test\Project\Problem\bin\
Debug\Problem.exe

Process returned 0 (0x0)   execution time : 0.017 s
Press any key to continue.

Debug Output :

Code
C:\Path\To\That\Test\Project\Problem/bin/
Debug/Problem.exe


What should I change in this project to have either only '\' or only '/' ?
I did not write any '\' or '/', it's only the system that is writing it  :-\ That's why I don't know how to have it another way  :(

I'm sorry, but I really don't get it *puzzled*

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Exectution Directory and Debbuger Working Directory
« Reply #10 on: February 28, 2012, 02:52:35 pm »
But your program fails in the second case, right?
It starts correctly and you execute some code which fails, because you don't expect to get the 'wrong' directory delimiters, right?
If I were you'd have found the code and I would have fixed it, already.

BTW: Have you tried a debugger's branch nightly build?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline le Pape

  • Single posting newcomer
  • *
  • Posts: 7
Re: Exectution Directory and Debbuger Working Directory
« Reply #11 on: February 28, 2012, 04:30:25 pm »
The nightly build solved it !

Yup, my program failed in the second case because of the inconsistency in path separator.

I had solved the problem with a workaround already, indeed (thanks to p2rkw :) ).
But it was a workaround (dirty workaround is dirty).
I was looking for a better way, and the debugger's branch nightly build did the trick :)

Thanks for your help !



PS : Still, if someone else has similar problem, it might be good to notice that there is still an inconsistency in behaviour between Run and Debug : running gives backward slashed only path while debugging gives forward slashed only path. Maybe that could cause trouble in another case as forward slash path at least were not standard for a long time on windows and might be unexpected in some libs.