I am trying to learn fortran. I wanted to replicate a certain step in a paper but I ran into trouble.
I compiled the file AERsimulation.f95 (I turned on all debugging functions in gfortran I am aware of) I could generate an .out file without any errors (a lot of warnings, however...)
When I tried to run the .out file I got the error message
Fortran runtime error: Index '0' of dimension 1 of array 'k' below lower bound of 1
Now, it is quite difficult for me to understand why exactly this happens. I guess, my question is, whether there is a better way of debugging, so that I can see and click through the code 'live' and see why the error occurs. (I am thinking of the matlab-debugger for instance...)
Any suggestion/hint is very welcome
The files I use are
AERsimulation.f95
AERDATANB.TXT
Thank you very much
Best
Derrick
The meaning of your error message is that you try to access an array element at the position 0 of the array. Arrays in Fortran start at 1 by default.
If you are looking for a better way to debug, try gdb (command line) or if you prefer a graphical interface you can try the Netbeans IDE. It has (limited) support for Fortran an a debugging mode where you can click line by line through the code and see the values of all variables and so on.
On command line try:
gdb name_of_executable
run
the debugger will stop at the line which causes the error.
Related
I feel like this is a common question, but I couldn't find anything on it. Often times when I compile a program, I'll have a long list of compilation errors, and I have to scroll up in the terminal to find the first error. This is kind of tedious and sometimes I scroll past the first error without noticing. Is there a quicker way to navigate this?
Terminal-specific approach:
$ clear && make
Then use the shortcut Shift+Home to jump to the top. This shortcut may not be available for all consoles. It seems to work for gnome-terminal and agetty. It does not seem to work for xterm, but I would assume that such consoles can be configured to add a shortcut (e.g. for xterm see link).
Compiler-specific approach:
Alternatively, you could use compiler mechanisms for limiting the number of errors to be shown. Both clang and gcc support -Wfatal-errors for exiting on the first error (not to be confused with -Werror which turns warnings into errors). From the gcc man page:
-Wfatal-errors
This option causes the compiler to abort compilation on the first
error occurred rather than trying to keep going and printing
further error messages.
Exiting on the first error might be unhelpful in some cases (i.e. when missing some header, there might be an error about a missing ; before the error telling you which identifier is undefined).
For this reason, it might be more helpful to limit the number of errors. For gcc there is -fmax-errors=n (for clang -ferror-limit=n) for showing at most n errors. You could adjust it to a small number that allows you to see all errors at once without scrolling.
-fmax-errors=n
Limits the maximum number of error messages to n, at which
point GCC bails out rather than attempting to continue
processing the source code. If n is 0 (the default), there is
no limit on the number of error messages produced. If
-Wfatal-errors is also specified, then -Wfatal-errors takes
precedence over this option.
I've generated an gfortran executable I call mtc08.exe that exhibits the following behavior:
1) If I run it in gdb it runs successfully to the end
2) If I run it normally, re routing the output with the windows command
mtc08.exe >out
It gives me "floating point exception - erroneous arithmetic operation" but does not say where that occurs. (The "backtrace" information is incomprehensible to me, and it seems it cannot contain much information because all is the letter "f".)
Then I'm trying to localize the problem by seeing where the program stops writing results, but having difficulties there also, because I get the impression the program may be multi tasking and proceeding with "future" arithmetic operations before completing output operations that in any case do not interfere.
Does such multi tasking occur? If so, can I turn it off with a compiler switch, so I'm really sure it is doing all operations sequentially?
The currently used compilation command in windows is:
rem debug compilation:
gfortran -static -fdefault-real-8 -fdefault-integer-8 -g -ffpe-trap=invalid,zero,overflow,underflow,denormal -Wall -fcheck=all #mtc08.fls -o mtc08.exe
where mtc08.fls is a file containing the names of all source files.
It may be that by removing some of the "-ffpe-trap" options it would run, but this rattles my confidence, and I'd like to get to the bottom of it, rather than just find a way around.
I can of course give more information, but seeing the error is not localized, that is not so practical.
I still don't know how to get better diagnostics, but still managed to find the cause of the problem by trial and error, which came from an uninitialized variable.
The problem appears to arise because gdb used zero for uninitialized variables, which should have been their values anyhow, and running the same executable without gdb did use values that lead to "floating point exception".
One way to get better diagnostics in gdb is to use -finit-real-nan in the compilation so that uninitialized variables will get more attention from the debugger.
Perhaps with better coding practice, such as intent declarations for all arguments, the debugger would also be better in picking up uninitialized variables without having to initialize them to nan.
This is homework. Tips only, no exact answers please.
I have a compiled program (no source code) that takes in command line arguments. There is a correct sequence of a given number of command line arguments that will make the program print out "Success." Given the wrong arguments it will print out "Failure."
One thing that is confusing me is that the instructions mention two system tools (doesn't name them) which will help in figuring out the correct arguments. The only tool I'm familiar with (unless I'm overlooking something) is GDB so I believe I am missing a critical component of this challenge.
The challenge is to figure out the correct arguments. So far I've run the program in GDB and set a breakpoint at main but I really don't know where to go from there. Any pro tips?
Are you sure you have to debug it? It would be easier to disassemble it. When you disassemble it look for cmp
There exists not only tools to decompile X86 binaries to Assembler code listings, but also some which attempt to show a more high level or readable listing. Try googling and see what you find. I'd be specific, but then, that would be counterproductive if your job is to learn some reverse engineering skills.
It is possible that the code is something like this: If Arg(1)='FOO' then print "Success". So you might not need to disassemble at all. Instead you only might need to find a tool which dumps out all strings in the executable that look like sequences of ASCII characters. If the sequence you are supposed to input is not in the set of characters easily input from the keyboard, there exist many utilities that will do this. If the program has been very carefully constructed, the author won't have left "FOO" if that was the "password" in plain sight, but will have tried to obscure it somewhat.
Personally I would start with an ltrace of the program with any arbitrary set of arguments. I'd then use the strings command and guess from that what some of the hidden argument literals might be. (Let's assume, for the moment, that the professor hasn't encrypted or obfuscated the strings and that they appear in the binary as literals). Then try again with one or two (or the requisite number, if number).
If you're lucky the program was compiled and provided to you without running strip. In that case you might have the symbol table to help. Then you could try single stepping through the program (read the gdb manuals). It might be tedious but there are ways to set a breakpoint and tell the debugger to run through some function call (such as any from the standard libraries) and stop upon return. Doing this repeatedly (identify where it's calling into standard or external libraries, set a breakpoint for the next instruction after the return, let gdb run the process through the call, and then inspect what the code is doing besides that.
Coupled with the ltrace it should be fairly easy to see the sequencing of the strcmp() (or similar) calls. As you see the string against which your input is being compared you can break out of the whole process and re-invoke the gdb and the program with that one argument, trace through 'til the next one and so on. Or you might learn some more advanced gdb tricks and actually modify your argument vector and restart main() from scratch.
It actually sounds like fun and I might have my wife whip up a simple binary for me to try this on. It might also create a little program to generate binaries of this sort. I'm thinking of a little #INCLUDE in the sources which provides the "passphrase" of arguments, and a make file that selects three to five words from /usr/dict/words, generates that #INCLUDE file from a template, then compiles the binary using that sequence.
hey guys i have a question regarding amzi prolog with eclipse,
Im running a .pro file which executes a breadth first search and if queue gets too long,
the following error message appears:
system_error 1021 Control stack full.
Compile code or increase .cfg
parameter 'control'
If so, how may i run the compiled code under eclipse? I've tried running the project but the listener just ends without accepting any queries....?
Control stack full means one of two things:
You have a deep recursion that exhausts the control stack. In that case you need to increase the default value of 'control' in your amzi.cfg file. You may find you that have to increase 'heap', 'trail' and/or 'local' as well.
You have an error in your program causing an infinite recursion.
Running the program in the debugger will show you which case you've got. In the initial case you will see it digging deeper and deeper for a solution. In the later case you will see it chasing it's tail in circles with each recursion the same as the one before, but with different variables.
I don't know amzi prolog (I only used SICStus and SWI), and never used Eclipse for prolog, but as the error message says, try compiling (instead of consulting) your code. Look under project/properties for build configurations (like run/deug, as it works for Java/C++). Hopefully, that ".cfg paramerer" can also be accessed through project/properties.
Is it possible for the debugger (or the CLR exception handler) to show the line where the exception happened in Release mode using the pdb?
The code, in release mode, is optimized and do not always follow the order and logic of the "original" code.
It's also surprising that the debugger can navigate through my code step by step, even in Release mode. The optimization should make the navigation very inconfortable.
Could you please clarify those two points for me?
I'm not as familiar with how this is done with CLR, but it's probably very similar to how it's done with native code. When the compiler generates machine instructions, it adds entries to the pdb that basically say "the instruction at the current address, X, came from line 25 in foo.cpp".
The debugger knows what program address is currently executing. So it looks up some address, X, in the pdb and sees that it came from line 25 in foo.cpp. Using this, it's able to "step" through your source code.
This process is the same regardless of Debug or Release mode (provided that a pdb is generated at all in Release mode). You are right, however, that often in release mode due to optimizations the debugger won't step "linearly" through the code. It might jump around to different lines unexpectedly. This is due to the optimizer changing the order of instructions, but it doesn't change the address-to-source-line mapping, so the debugger is still able to follow it.
[#Not Sure] has it almost right. The compiler makes a best effort at identifying an appropriate line number that closely matches the current machine code instruction.
The PDB and the debugger don't know anything about optimizations; the PDB file essentially maps address locations in the machine code to source code line numbers. In optimized code, it's not always possible to match exactly an assembly instruction to a specific line of source code, so the compiler will write to the PDB the closest thing it has at hand. This might be "the source code line before", or "the source code line of the enclosing context (loop, etc)" or something else.
Regardless, the debugger essentially finds the entry in the PDB map closest (as in "before or equal") to the current IP (Instruction Pointer) and highlights that line.
Sometimes the match is not very good, and that's when you see the highlighted area jumping all over the place.
The debugger makes a best-effort guess at where the problem occurred. It is not guaranteed to be 100% accurate, and with fully optimized code, it often will be inaccurate - I've found the inaccuracies ranging anywhere from a few lines off to having an entirely wrong call stack.
How accurate the debugger is with optimized code really depends on the code itself and which optimizations you're making.
Reference the following SO question:
Display lines number in stack trace for .NET assembly in release mode