Fortran Programming Language
"init.c: No such file or directory."
Hi, I am using PGI fortran with MPI (mpif90), and when I compiled and
ran my program, I got the segementation fault error. (As a matter of
it did not execute the first executable statement in my program, which
printning 'hello world'.)
I ran the program with a debugging option (gdb) and I got the
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
This GDB was configured as "i386-redhat-linux"...
Breakpoint 1 at 0x81bbfe6
Program received signal SIGSEGV, Segmentation fault.
0x40000a50 in .BSS1 ()
1 init.c: No such file or directory.
So I am not really understanding why my program
has anything to do with 'init.c' (I don't actually know what it is).
Does anybody know what these messages imply?
Some Fortran compiles (most) compile to the C language then compile/
link this new intermediate code. To do so you also need a C compiler
and a few fundementals, one of which is the init.c module.
I think that is your problem. Check the installation manual or User's
DVF comes (came) with C++ embedded.
Intel Fortran requires Mirosoft C== as a condition of compile-linking
We're nerds. We like consistency. "Claire" is a perfectly nice name.
You should continue to use it unless you are legally changing your name
to "Jane Smith," which is also a perfectly nice name.
On to your problem:
I would guess that init.c is part of the Fortran library with which your
program is linked. I would also expect that the code in init.c calls
your main program.
My first question would be: Can you get a very simple program -- one
that does *nothing* but say "Hello, world" -- to run with this compiler?
If you can't, then you may have a compiler installation problem. Or
you could be linking to the wrong library somehow.
If you *can* get trivial programs to work, but your program won't, then
(obviously) there's something about your program. There might be arrays
that are too big. Or it could be something else.
I would try to trim your program until it starts working and then see
what the difference is between a version that works and one that fails.
The results can be surprising, so I would advise approaching this
methodically and with an open mind. I've spent hours doing this.
If you can read the machine code on your system, you could ask gdb to
tell you what instruction is failing at address 0x40000a50. This
*might* give you a clue as to what's wrong.
If your Fortran compiler generates the equivalent of a C++ static
initializer, and if it calls a constructor with a bug, you might see
something like this. But that's just a really wild guess.
No, most do not. In particular, the one used by the OP does not. See my
> Some Fortran compiles (most) compile to the C language then compile/
> link this new intermediate code.
simillar, but longer, reply in the other thread.
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
On May 27, 6:15 am, Louis Krupp <firstname.lastname@example.org>
Thank you very much. To isolate the issues, I ran a program that only
prints out '
hello world' messages, and it worked perfectly. And, as you said, my
use big arrays. So, following your advice, I am gonna trying
increasing the complexity
of the program to see how far it can go.
I've tried starting with a working version and building it up to the
point where it fails, and my experience with that method hasn't been
good. The problem is that I never know what triggers the problem.
I would suggest starting with a failing version and deleting stuff until
it works. I have gone as far as doing a sort of binary search for the
1. Start with something that fails.
2. Delete the second half.
3. If the remainder fails the same way, go to step 2. If it works,
delete the last quarter of the code, and repeat step 3.
If you see that, say, it fails if you include line 1200 of a 2000-line
program but fails without it, then you might have enough information to
make a guess as to what the problem is. If not, you'll have to try to
delete irrelevant parts of the first 1199 lines until you have a minimal
example. This can be time-consuming. I used to do this when I was
porting C++ code (I made a living doing that for about five years, which
tells you something about what C++ was like at that time) and it was the
only way I knew how to generate sample files for reporting compiler
bugs. Hopefully, you're not dealing with something that strange.
If you want to see if your array sizes have something to do with it, you
could do the same sort of binary search:
If it fails with array size 65536, try 32768. If that fails, try 16384.
If 32768 works, try 32768 + 16384, etc. You may have more than one
large array, in which case it gets more complicated.
One of the suggestions I've seen in this group is to increase the stack
size. If you have a huge statically allocated array, this might help.
The above array size trick might help you determine if this in fact a
problem. Or you could just try it; it might be quicker than going
through all the stuff I was talking about.
Try not to have too much fun.
Another thought: Your debugger is a few years old (2002). How old is
the rest of your environment -- Fortran compiler, library, etc? Could
you update to something newer? There's nothing more frustrating than
trying to work around a problem that's been fixed.
On May 28, 3:25 am, Louis Krupp <email@example.com>
Thank you so much for your invaluable advice. I am now trying
tailoring the program from the failing version.
As for the system, I am using the cluster system set up by the
department, so I don't have much discretion over it.
But, I would have nothing to lose by asking the IT staff to update