Re: "init.c: No such file or directory."
- From: Louis Krupp <lkrupp@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 28 May 2007 01:18:40 -0600
Jane Smith wrote:
On May 27, 6:15 am, Louis Krupp <lkr...@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Jane Smith wrote:Hi, I am using PGI fortran with MPI (mpif90), and when I compiled andWe're nerds. We like consistency. "Claire" is a perfectly nice name.
ran my program, I got the segementation fault error. (As a matter of
fact,
it did not execute the first executable statement in my program, which
was
printning 'hello world'.)
I ran the program with a debugging option (gdb) and I got the
following messages.
-------------------------------------------------------------------------------
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
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Breakpoint 1 at 0x81bbfe6
Program received signal SIGSEGV, Segmentation fault.
0x40000a50 in .BSS1 ()
(gdb) list
1 init.c: No such file or directory.
in init.c
---------------------------------------------------------------------------------
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?
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.
Have fun.
Louis
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
program does
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 problematic code:
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.
Louis
.
- References:
- "init.c: No such file or directory."
- From: Jane Smith
- Re: "init.c: No such file or directory."
- From: Louis Krupp
- Re: "init.c: No such file or directory."
- From: Jane Smith
- "init.c: No such file or directory."
- Prev by Date: Re: internal read of character array. F/ifort differences
- Next by Date: Re: "init.c: No such file or directory."
- Previous by thread: Re: "init.c: No such file or directory."
- Next by thread: Re: "init.c: No such file or directory."
- Index(es):
Relevant Pages
|
