Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Segmentation Fault - How can you detect?


Hi, I am a rookie using PGI fortran with MPI.
While I was trying to run my program called 'estimate' by typing in

 mpirun -nodegroup both -np 22 -machinefile machineset estimate

I got the following error message.

/usr/local/mpich/mpich-1.2.5_pgi/bin/mpirun: line 1: 18777
Segmentation fault      /home/shlim/Programs_MPI/estimate -p4pg /home/
shlim/Programs_MPI/PI18227 -p4wd /home/shlim/Programs_MPI

I know what segmentation fault generally means, but how can you find
exactly which line
in the source code is causing the problem?
I am thinking that 'line 1' wouldn't be any particular line in the
SOURCE file, so
how do you detect which line is causing the problem?

I used to use compaq visual fortran which gave pretty clear message
about
which line is causing the error, even in the run-time, and now in the
unix-pgi fortran,
I am kind of lost, regarding how to detect the problem.

On May 25, 4:44 pm, claire <claire.s.@gmail.com> wrote:

G95 has compiler options -ftrace=full -fbounds-check to display line
numbers of errors. Maybe you could try debugging with g95.

Have you looked at the PGI compiler manual for similar options? What
compiler options are you using?

On May 25, 5:32 pm, Beliavsky <beliav@aol.com> wrote:

Thank you very much. I am using the compiler pgf90, and I found
in the manual, the option '-g' that
generates symbolic debugging information and keeps track of program
variables and source code.
And, I tried it, but it is not really making any difference.
I get exactly the same messages w/o information about lines in the
source files.
I don't know what to do..

Claire

In article <1180162558.726863.89@m36g2000hse.googlegroups.com>, claire wrote:
> Thank you very much. I am using the compiler pgf90, and I found
> in the manual, the option '-g' that
> generates symbolic debugging information and keeps track of program
> variables and source code.
> And, I tried it, but it is not really making any difference.
> I get exactly the same messages w/o information about lines in the
> source files.
> I don't know what to do..

With PGI, use the options "-g -Mbounds -Mchkfpstk" for some extra checking.

The point with the debugging symbols is that you get some sensible
information when looking at the program with the debugger. After your
program fails, it will write out a file called "core" or something
like that. If it doesn't, run "ulimit -c unlimited" and try
again. Then you can use the debugger to see where it
failed. E.g. "pgdbg /path/to/your/program /path/to/core/file" to start
the debugger and load the program and associated core file. Hopefully
the debugger command "bt" will then show where in your program the
crash occured.

--
Janne Blomqvist

On May 26, 4:31 am, Janne Blomqvist <f@bar.invalid> wrote:

Okay. By setting environment variable PGI_TERM=debug, trace, signal,
abort
I made the compiler generate the core file.
And, I tried, and I got the following messages.

]$ pgdbg estimate.out core.2094

PGDBG 4.0-2 (Workstation, 4 CPU)
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2002, STMicroelectronics, Inc. All Rights Reserved.
PGDBG cannot open a window; check the DISPLAY environment variable.
Entering text mode.
        *** Reading dwarf
Segmentation fault (core dumped)

Then, since my program is using parallelized (MPI), I also tried two
other following
options.

--------------------------------------------------------------------------- ----
]$ mpirun -nodegroup both -dbg=pgdbg -np 22 -machinefile machineset
estimate.out
Cannot run debugger - no debugger script.

]$ mpirun -nodegroup both -dbg=gdb -np 22 -machinefile machineset
estimate.out
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 0x81b9d86

Program received signal SIGSEGV, Segmentation fault.
0x40000a50 in .BSS1 ()
(gdb) list

1       init.c: No such file or directory.
        in init.c

--------------------------------------------------------------------
At this point, I believe that I got close to identifying what is the
problem,
but I will still have tackle why 'init.c' is in there and how it is
causing the problem.
Thank you very much to the two people who gave the advice above.

Segmentation faults occur when the compiler has reached an
understanding of the code and data space it needs.
This is usually during or after it has compiled the intermediate
language, usually "C".
As I said in another post to a question by Jane, "init.c" is a module
requested to be included in the intermediate code generated by the
Fortran compiler, prior to "C" compilation. If it is not there the "C"
compiler will report it cannot find this module.

Probabilty - an installition error for one of the compilers (needs the
"C" compiler installed first).

Terence <tbwri@cantv.net> wrote:
> Segmentation faults occur when the compiler has reached an
> understanding of the code and data space it needs.

I assume there are qualifiers missing in the above sentence. I don't see
enough context to even guess what they might be and thus what you might
be trying to say. But I wouldn't have posted just to note that.

> This is usually during or after it has compiled the intermediate
> language, usually "C".

This is what I posted to correct.

The "usually" here is incorrect by any measure. "Rarely" would be more
accurate. It is rare for a Fortran compiler to use C as an intermediate
language. There exist Fortran compilers that do, but most do not.
Off-hand, the only examples I can think of that do are f2c and some
versions of the NAG compiler. It is concievable that there are other
historical examples. I almost added the old PSR compiler, but then
remembered that it used Fortran as an intermediate - not C. (Yes, it did
Fortan to Fortran, trying to fake an f90 compiler by translating into
f77; but it did a darned poor job.)

People occasionally claim that other Fortran compilers, particularly
g77, g95, and gFortran, use C as an intermediate language, but such
people are misinformed.

In the particular case at hand, no the PGI compiler that the OP is using
is not one of the rare ones that uses C as an intermediate language.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Richard,
The Intel Fortran compilers series V9 require the Microsoft "C"
compiler to be installed first.
That is one of the conditions listed in the installation directions.
When I ordered the 9.0 version as part of Intel taking over the CVF/
DVF compiler I was being supported on, I was written to, telling me I
had to get and install the Miscrosoft "C++" compiler first and install
it before the Intel 9.0 - note, not Intel's OWN C++ compiler but
Microsoft's version. My guess is the reason may be that Intel uses the
API library from the Microsoft C++ system. And this in turn has
include files needed.

This V9.0 (now 9.1)  is the Fortran compiler Intel used to replace the
DVF compiler they took over.
But that init.c is a file in the C section of source code include
files in my computer and there are similar names init.cpp in the c++
directories. Both postngs of message noting this name probably are
installation problems, perhaps requiring a C++ compiler on the system.

Terence wrote:
> Richard,
> The Intel Fortran compilers series V9 require the Microsoft "C"
> compiler to be installed first.
> That is one of the conditions listed in the installation directions.
> When I ordered the 9.0 version as part of Intel taking over the CVF/
> DVF compiler I was being supported on, I was written to, telling me I
> had to get and install the Miscrosoft "C++" compiler first and install
> it before the Intel 9.0 - note, not Intel's OWN C++ compiler but
> Microsoft's version. My guess is the reason may be that Intel uses the
> API library from the Microsoft C++ system. And this in turn has
> include files needed.

I believe that's for the run time libraries and possibly the linker.  It
doesn't use the actual compiler.

> This V9.0 (now 9.1)  is the Fortran compiler Intel used to replace the
> DVF compiler they took over.
> But that init.c is a file in the C section of source code include
> files in my computer and there are similar names init.cpp in the c++
> directories. Both postngs of message noting this name probably are
> installation problems, perhaps requiring a C++ compiler on the system.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Terence <tbwri@cantv.net> wrote:
> The Intel Fortran compilers series V9 require the Microsoft "C"
> compiler to be installed first.

That's true...or I think so. I forget whether that might be just for the
IDE or more generally, but in any case it is not because the compiler
uses C as an intermediate language; it doesn't.

Also, that wasn't teh compiler used by the OP.

> Both postngs of message noting this name probably are
> installation problems, perhaps requiring a C++ compiler on the system.

That's possible. I don't have enough data/insight to know for sure
either way.

I just wanted to correct the part about using C as an intermediate
language. That's a misconception that enough people have anyway; I
didn't want to see encouragement of teh misconception. Again, requiring
that the C compiler be installed (or at least the C compiler runtimes)
is not the same thing as using C as an intermediate language. I'd agree
that requiring C runtime libraries to be installed is common.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

I have no experience with PGI compilers, but in other cases a problem
in line 1 often meant there had been a problem with compiling and/or
linking, and the executable had no real MAIN routine. Are you sure
that you had no errors in compiling and linking? Does your 'estimate'
look reasonable?

Matthias

Matthias SCHROEDER wrote:
> claire <claire.s.@gmail.com> writes:

(snip)

>>/usr/local/mpich/mpich-1.2.5_pgi/bin/mpirun: line 1: 18777
>>Segmentation fault      /home/shlim/Programs_MPI/estimate -p4pg /home/

(snip)

> I have no experience with PGI compilers, but in other cases a problem
> in line 1 often meant there had been a problem with compiling and/or
> linking, and the executable had no real MAIN routine. Are you sure
> that you had no errors in compiling and linking? Does your 'estimate'
> look reasonable?

I believe in this case that mpirun is a unix shell
script, and line 1 is the line in the script that was
being executed at the time.

-- glen

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc