GDB fails to open file when debugging f77 program - gdb

So I'm not a big CS guy, so bear with me as I try to explain this adequately enough.
At work, I use a program written in Fortran 77 to do some modeling. Our debugging has been an issue, due to some IT constraints that are outside my control. When we attempt to use GDB, the compiler loads. When you run the program, it fails through internal logic checks. The program's looking for an input file, but it can't find it because GDB does not load another file that has a list of all the directories the input file, and other relevant files, could possibly be in.
The relevant code:
...
logical exst
...
INQUIRE(FILE='KEYWORDS',EXTST=exst)
if(exst)then
...
endif
End code
This DOES work when I run the program. The KEYWORDS file is found, read in through a call within the if statement branch, which allows the program to find the input file. When debugging, however, exst is always false, preventing proper read in, and failing later through logic checks.
Does GDB require certain permissions? The only thing I could find in my own search was a possible issue on signed/unsigned reported file size incompatibility, but outside of understanding what signed and unsigned values are, the explanation was a bit over my head.
Any help is appreciated. Will try to provide more information where requested.

gdb doesn't change the permissions of the program it runs. It runs under the same user id, as usual.
Normally when this sort of problem arises, it comes from an environmental difference. Typical sources are the current working directory, the command-line arguments, or environment variables. It's also reasonably common to have a wrapper script that invokes a program properly, but then when running in gdb, one does not use the wrapper and then improperly duplicates the setup that it provides. Less common but also still possible is code in .gdbinit messing with the environment inside gdb. So be sure to double-check things with pwd inside gdb, etc.

Related

Is striping certain information from a C++ binary safe?

I am brand new to C++, trying to create a program to read pixels on the screen on Linux.
I currently compile the project without any optimization flag, as I am unsure what it does to the program, but that would be another question, here's mine:
Is striping certain information from a C++ binary safe?
I found a possibly helpful manual page of strip program.
As I don't really know what striping means in this context, I am unsure if it is as simple as striping all of it with:
-s --strip-all Remove all symbol and relocation information
But, of course, I'd want the program to work flawlessly then, so does it interfere anyhow with program's execution?
As for my motivation for striping: I want to know if it's safe, and as I said already, I repeat:
I don't really know what striping means in this context.
I thought the answerer could have also covered this. For me to decide.
Symbols are used for debugging.
Your application would continue to work with out issues if you strip them; but you may find it harder to debug if there's a problem.
Relocation information is used for dynamic library loading and for address space layout randomisation (thank you #interjay); and from the strip documentation
--remove-relocations=sectionpattern
... Note that using this option inappropriately may make the output file unusable. ...

Is there a way to figure out what environment variables are needed/used by an executable?

I've got a C++ program that will run certain very specific commands as root. The reason this is needed is because another program running under Node.js needs to do things like set system time, set time zone, etc that require root privileges to accomplish. I'm using the function execve in C++ to make the system call with root privileges after using the setuid command. I specifically choose the execve command because I want to wall off the environment so I don't create an environment variable vulnerability.
setuid(0);
execve(acExeName, pArgsForExec2, pcEnv);
What I want to do is find out exactly the pcEnv which is the environment variable list for the program to execute with that my program needs. For example, if I want to run the tool time-admin as if I was running it from the console, how can I figure out what environment variables it needs. I know I can print off the environment variables with the command printenv, but that gives me all of them. I'm quite sure I don't need them all and want as small a subset as possible.
I know I can use them all and then slowly comment each one out and see if it keeps working, but I'd really rather not go that far.
Anyone got a clever way to figure out what environment variables are used by a program? I should add I'm doing this on a Ubuntu 12.04 LTS install.
Thanks for any help.
There are no general ways of figuring out the environment variables used by some program. For example, one could imagine that a program has some configuration files which gives the name of environment variables.
Actually many shell like programs (or script interpreters) are doing that.
More generally, the argument to getenv(3) could be computed. So in theory you cannot guess its possible values. (I might be wrong, but some very old versions of libc and of bash used to play such tricks; unfortunately, I forgot the details, but sometimes an environment variable with some pid number in its name was used).
And, as others commented, you might want to use ltrace (or play LD_PRELOAD tricks), or use gdb, to find out how getenv is called ...
And the application might also use the environ variable (see environ(7) ...) or the third argument to main ....
In practice however, a reasonably written program should clearly document all the environment variables it is using....
If you have access to the source code of the program, you could, if it is compiled by GCC, use (the just released version 1.0 of) the MELT plugin. MELT is a domain specific language to extend GCC and can be used to explore the internal Gimple representations handled by GCC while compiling your program. In particular with its new findgimple mode you could find in one command all the calls to getenv with a constant string.

Debugging: Tracing (and diff-ing) function call tree of two version of the same program

I'm working on the rewriting of some
code in a c++ cmd line program.
I
changed the low level data structure that
it uses and the new version passes all
the tests (quite a lot) without any
problem and I get the correct output
from both the new and the old version...
Still, when give certain input, they give
different behaviour.
Getting to the point: Being somewhat of
a big project I don't have a clue about
how to track down when the execution
flow diverges, so... is there way to trace
the function call tree (possibly excluding
std calls) along with, i don't know, line
number in the source file and source
name?
Maybe some gcc or macro kungfu?
I would need a Linux solution since that's where the program runs.
Still, when give certain input, they give different behaviour
I would expand logging in you old and new versions in order to understand better work of your algorithms for certain input. When it become clearer you can for example use gdb if you still need it.
Update
OK, As for me logging is OK, but you do not want to add it.
Another method is tracing. Actually I used it only on Solaris but I see that it exists also on Linux. I have not used it on Linux so it is just an idea that you can test.
You can use SystemTap
User-Space Probing SystemTap initially focused on kernel-space probing. However, there are many instances where userspace probing can
help diagnose a problem. SystemTap 0.6 added support to allow probing
userspace processes. SystemTap includes support for probing the entry
into and return from a function in user-space processes, probing
predefined markers in user-space code, and monitoring user-process
events.
I can gurantee that it will work but why don't give it a try?
There is even an example in the doc:
If you want to see how the function xmalloc function is being called
by the command ls, you could use the user-space backtrack functions to
provide that information.
stap -d /bin/ls --ldd \
-e 'probe process("ls").function("xmalloc") {print_ustack(ubacktrace())}' \
-c "ls /"

Reverse engineering your own code c++

I have a compiled program which I want to know if a certain line exist in it. Is there a way, using my source code, I could determine that?
Tony commented on my message so I'll add some info:
I'm using the g++ compiler.
I'm compiling the code on Linux(Scientific)/Unix machine
I only use standard library (nothing downloaded from the web)
The desired line is either multiplication by a number (in a subfunction of a while group) or printing a line in a specific case (if statement)
I need this becouse I'm running several MD simulations and sometimes I find my self in a situation where I'm not sure of the conditions.
objdump is a utility that can be used as a disassembler to view executable in assembly form.
Use this command to disassemble a binary,
objdump -Dslx file
Important to note though that disassemblers make use of the symbolic debugging information present in object files(ELF), So that information should be present in your object files. Also, constants & comments in source code will not be a part of the disassembled output.
Summary
Use source code control and keep track of which source code revision the executable's built from... it should write that into the output so you can always cross-reference the two, checkout the same sources and rebuild the executable that gave you those results etc..
Discussion
The desired line is either multiplication by a number (in a subfunction of a while group) or printing a line in a specific case (if statement)
I need this becouse I'm running several MD simulations and sometimes I find my self in a situation where I'm not sure of the conditions.
For the very simplest case where you want all the MD simulations to be running the latest source, you can compare timestamps on the source files with the executable to see if you forgot to recompile, compare the process start time (e.g. as listed by ps) with the executable creation time.
Where you're deliberately deploying multiple versions of the program and only have the latest source, then it gets pretty tricky. A multiplication will typically only generate a single machine code instruction... unless you have some contextual insight you're unlikely to know which multiplication is significant (or if it's missing). The compiler may generate its own multiplications for e.g. array indexing, and may sometimes optimise multiplications into bit shifts (or nothing, as Ira comments), so it's not as simple as saying 'well, it's my only multiplication in function "X"'. If you're printing a specific line that may be easier to distinguish... if there's a unique string literal you can search for it in the executable (e.g. puts("Hello") -> strings program | grep Hello, though that may get other matches too, and the compiler's allowed to reuse string literal sequences so "Well Hello" might cater to your need via a pointer to 'H' too). If there's a new extern symbol involved you might see it in nm output etc..
All that said (woah)... you should do something altogether different really. Best is to use a source control system (e.g. svn, cvs...), and get it configured so you can do something to find out which revision of the codebase was used to create the executable - it should be a FAQ for any revision control system.
Failing that, you could, for example, do something to print out what multipliers or conditions the progarm was using when it starts running, capturing that in your logs. While hackish, macros allow you to "stringify" their parameters, so you can log and execute something without typing all the code twice. Lots of other options too.
Hope some of that helps....

Using program as library that contains main function

I am planning to write a program that makes calls to cdrecord. (I am a beginner, a beginner trying to "scratch an itch") The program would be written in C++. I have identified that I need to be able to run cdrecord in order for this to work.
cdrecord is written in C. However the documentation on using it is from the command line. The source code includes a main function that powers the command line app, which is the same as the code I wand cdrecord to do.
I am wondering whether I should:
Change main to another name, then include the source file and call it when I need to.
Call the compiled program using the system() command.
Something else.
system() is generally a nice way to go, just be careful not to inject arbitrary untrusted values into the string you execute. For example, if you have a web frontend where with a padsize option defaulted to 0, and someone types in not a number but "0; rm -rf *;", make sure you don't end up calling "cdrecord padsize=0; rm -rf *; ...".
The other thing with system is just that it can be slower starting a second distinct process - this might matter if you're running that program hundreds of times and each time it only has a few milliseconds of work to do, but in your case the overhead of launching is dwarfed by the likely cdrecord run-time.
Using system() will allow you to not worry about cdrecord's code. Personally, I would only include the code in my own program if I had some very pressing issues that require me to include it. I think system() is the way to go.
http://www.cplusplus.com/reference/clibrary/cstdlib/system/
1) Is there any particular reason you would rather include it in your own code, as opposed to just using it as it is?
2) Do you have the rights to change the code and include it in your own program?