Segmentation Fault: When attempting to run Sun Fortran code on Linux 
Author Message
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Greetings,

I am curious if anyone out there has had problems running fortran
codes from a Sun  machine on a Linux machine.  I get SEGMENTATION
FAULTS, is there anything particular I need to keep in mind when
porting from Sun to Linux?  My code uses lot of complex statements,
common blocks and do loops and I am not using any 64bit specific
coding for my variables.  To the best of my knowledge I haven't found
statements that may be writing outside of allocated memory blocks to
cause seg. faults.  This code works great on the Sun machine so I am
thinking there might be something else I am missing when trying to run
it on Linux.  Any help will be greatly appreciated!


My System Info:

SUN MACHINE
#uname -rs
SunOS 5.8
#gcc -v
Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)

LINUX MACHINE
Distribution: RH 9.0
# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
# uname -rs
Linux 2.4.20-8



Sun, 02 Oct 2005 23:47:36 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:

> Greetings,

> I am curious if anyone out there has had problems running fortran
> codes from a Sun  machine on a Linux machine.  I get SEGMENTATION
> FAULTS, is there anything particular I need to keep in mind when
> porting from Sun to Linux?  My code uses lot of complex statements,
> common blocks and do loops and I am not using any 64bit specific
> coding for my variables.  To the best of my knowledge I haven't found
> statements that may be writing outside of allocated memory blocks to
> cause seg. faults.  This code works great on the Sun machine so I am
> thinking there might be something else I am missing when trying to run
> it on Linux.  Any help will be greatly appreciated!

First steps I take:
1) Compile from scratch with:
   -all message output on
   -optimisation off
   -array index checking on
   -debug on.
1a) Attend to all WARNING and CAUTION level messages that the compile spits out. Return to
step 1.
2) Run the code in a de{*filter*}.
3) When the code crashes in this environment, it's _usually_ pretty easy to figure out
why.

My rather limited experience has shown that seg faults are always the programmer's (i.e.
my) fault. That's not to say it couldn't be something else...just unlikely.

cheers,

paulv

--
Paul van Delst

Ph: (301)763-8000 x7748
Fax:(301)763-8545



Mon, 03 Oct 2005 00:26:27 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux
Thanks for the advice Paul, it turns out my initilization subroutine
was causing the seg fault as pointed out in the de{*filter*}.  Aparently
on the Sun machine initilizing declared variables in a subroutine
prior to program execution doesn't cause any problems but it does with
Linux.  That seems to take care of this problem.  Thanks again for
your help.

I am curious do you have any experience with running fortran CFD codes
written on a SUN platform on a Linux machine as I am faced with some
unusual errors, my program on certain situation when having say the
nonliner terms withing the program on or off will hang during
execution with following type of error, where it prints one statement
and then pauses, but there are no pause statements anywhere in the
program, any ideas? The de{*filter*} doesn't provide anything more than
this either.

#a.out
 1 57600  0.00347222225 nc= 0 dec
PAUSE  statement executed
To resume execution, type go.  Other input will terminate the job.

I get the feeling I may be compromising on the numerical accuracy of
my program in running it in this manner that's why I wanted to address
any issues that may be special to this type of migration from SUN to
LINUX.

Once again thanks for your help in advance.

Nathan Simmons
Aerosapce Engineering Sciences
CU Boulder


Quote:

> > Greetings,

> > I am curious if anyone out there has had problems running fortran
> > codes from a Sun  machine on a Linux machine.  I get SEGMENTATION
> > FAULTS, is there anything particular I need to keep in mind when
> > porting from Sun to Linux?  My code uses lot of complex statements,
> > common blocks and do loops and I am not using any 64bit specific
> > coding for my variables.  To the best of my knowledge I haven't found
> > statements that may be writing outside of allocated memory blocks to
> > cause seg. faults.  This code works great on the Sun machine so I am
> > thinking there might be something else I am missing when trying to run
> > it on Linux.  Any help will be greatly appreciated!

> First steps I take:
> 1) Compile from scratch with:
>    -all message output on
>    -optimisation off
>    -array index checking on
>    -debug on.
> 1a) Attend to all WARNING and CAUTION level messages that the compile spits out. Return to
> step 1.
> 2) Run the code in a de{*filter*}.
> 3) When the code crashes in this environment, it's _usually_ pretty easy to figure out
> why.

> My rather limited experience has shown that seg faults are always the programmer's (i.e.
> my) fault. That's not to say it couldn't be something else...just unlikely.

> cheers,

> paulv



Mon, 03 Oct 2005 13:17:44 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:

> Greetings,

> I am curious if anyone out there has had problems running fortran
> codes from a Sun  machine on a Linux machine.  I get SEGMENTATION
> FAULTS, is there anything particular I need to keep in mind when
> porting from Sun to Linux?  My code uses lot of complex statements,
> common blocks and do loops and I am not using any 64bit specific
> coding for my variables.  To the best of my knowledge I haven't found
> statements that may be writing outside of allocated memory blocks to
> cause seg. faults.  This code works great on the Sun machine so I am
> thinking there might be something else I am missing when trying to run
> it on Linux.  Any help will be greatly appreciated!



Try running your program on Solaris using bcheck.

                                               Sincerely,
                                               Bob Corbett



Mon, 03 Oct 2005 15:32:56 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:

> Thanks for the advice Paul, it turns out my initilization subroutine
> was causing the seg fault as pointed out in the de{*filter*}.  Aparently
> on the Sun machine initilizing declared variables in a subroutine
> prior to program execution doesn't cause any problems but it does with
> Linux.

There is certainly nothing wrong with "initilizing declared variables
in a subroutine prior to program execution".  That is perfectly
standard and works with all compilers, including all linux
ones....assuming that you do it correctly.  Without more details, I
can't tell what was actually wrong, but I'm pretty sure it isn't what
you described above.  There are lots of things related to initialization
that could be problems.  For example

1. If you are assuming that things will be initialized without needing
   you to explicitly say so in the code, that can be a problem.  You
   sounded like you were saying that you *did* initialize variables, but
   I could imagine miscommunication on that matter.  If you did not
   initialize variables that needed to be, then yes, that is an area of
   known difference in compilers (g77 has a switch to control this
   behavior).

2. If you assume that initialization happens on every call instead of
   at the beginning of execution, that can be a problem (though your
   description seems to indicate that you understand this one),

3. If you fail to use SAVE properly for initialized variables, that
   can be a problem in f77 (at least in theory - actual cases of this
   failing for initialized data are less common).

4. If you try to initialize things in COMMON, that can be a problem.

or, I'm sure a bunch of other possibilities.  But I'm quite confident
that initialization doesn't itself cause problems.  Misused initialization
might.

P.S. The one exception I can think of involves shared libraries.  Making
initialization do the "right" thing in shared libraries might be tricky.
I don't know all the tricks and issues - I just can imagine it as a
problem.  But you didn't mention building shared libraries, and it is such
an important issue that I'd *hope* you would have mentioned it if you
were trying to do such a thing.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Mon, 03 Oct 2005 22:49:22 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:


> > Greetings,

> > I am curious if anyone out there has had problems running fortran
> > codes from a Sun  machine on a Linux machine.  I get SEGMENTATION
> > FAULTS, is there anything particular I need to keep in mind when
> > porting from Sun to Linux?  My code uses lot of complex statements,
> > common blocks and do loops and I am not using any 64bit specific
> > coding for my variables.  To the best of my knowledge I haven't found
> > statements that may be writing outside of allocated memory blocks to
> > cause seg. faults.  This code works great on the Sun machine so I am
> > thinking there might be something else I am missing when trying to run
> > it on Linux.  Any help will be greatly appreciated!


> Try running your program on Solaris using bcheck.

>                                                Sincerely,
>                                                Bob Corbett

Hey Bob thanks for introducing a new tool to me, bcheck runs my
executables under Solaris with no problems.  Again I wasn't having any
of these segmentation faults under SUN, everything was working well up
until I tried porting the code under Linux that's when I started
running into all these issues.  May be I need a commercial compiler
package like (Absoft Fortran Pro).  I was trying to see if anyone out
there was able to sucessfully use GNU Fortran Compiler in Linux to
port SUN fortran codes and run the executables sucessfully.  Or if
they would have advice for a commercial product that they have enjoyed
sucess with and could make some recommendation.

Nathan Simmons.



Tue, 04 Oct 2005 12:32:31 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:


> > Thanks for the advice Paul, it turns out my initilization subroutine
> > was causing the seg fault as pointed out in the de{*filter*}.  Aparently
> > on the Sun machine initilizing declared variables in a subroutine
> > prior to program execution doesn't cause any problems but it does with
> > Linux.

> There is certainly nothing wrong with "initilizing declared variables
> in a subroutine prior to program execution".  That is perfectly
> standard and works with all compilers, including all linux
> ones....assuming that you do it correctly.  Without more details, I
> can't tell what was actually wrong, but I'm pretty sure it isn't what
> you described above.  There are lots of things related to initialization
> that could be problems.  For example

> 1. If you are assuming that things will be initialized without needing
>    you to explicitly say so in the code, that can be a problem.  You
>    sounded like you were saying that you *did* initialize variables, but
>    I could imagine miscommunication on that matter.  If you did not
>    initialize variables that needed to be, then yes, that is an area of
>    known difference in compilers (g77 has a switch to control this
>    behavior).

> 2. If you assume that initialization happens on every call instead of
>    at the beginning of execution, that can be a problem (though your
>    description seems to indicate that you understand this one),

> 3. If you fail to use SAVE properly for initialized variables, that
>    can be a problem in f77 (at least in theory - actual cases of this
>    failing for initialized data are less common).

> 4. If you try to initialize things in COMMON, that can be a problem.

> or, I'm sure a bunch of other possibilities.  But I'm quite confident
> that initialization doesn't itself cause problems.  Misused initialization
> might.

> P.S. The one exception I can think of involves shared libraries.  Making
> initialization do the "right" thing in shared libraries might be tricky.
> I don't know all the tricks and issues - I just can imagine it as a
> problem.  But you didn't mention building shared libraries, and it is such
> an important issue that I'd *hope* you would have mentioned it if you
> were trying to do such a thing.

Dear Richard,

Thanks for a detailed resonse to my inquiry.  You point out a few
scenerios that I hadn't realized, which would prove important for
general debugging.  My main concern is that the code functions
perfectly well under Solaris 2.8, there are no issues or porblems.
The initilized variables are 4 dimensional complex numbers passed to a
subroutine that initilizes each element to a value CMPLX(0.,0.).  They
aren't in a COMMON blocks, they are defined as
COMPLEX CXS(3,0:Mmax,0:NPL,NZ),CFI(3,0:mmax,0:NPL) both in the main
program and in the subroutine and all the dependent varibles are also
defined.

My compilation and execution works without a flaw in Solaris but Linux
causes these problems.  What is the SAVE method, do I need to
implement this with g77 for it to do what was already done without the
SAVE command on Solaris?

I don't use any shared libraries either, I was able to execute the
code without seg fault when I commented out the call to initilization
subroutine so I assumed it was either my lack of understanding for
special case associated with g77.  I assumed it wasn't programmer (my)
error since everything has worked without problems in Solaris and thus
any errors could be attributed to Linux/g77.

Here is what the Call from main program and Subroutine look like, I
coment the call in the main program and the SEG FAULT is gone.

By the way would you have any references for information in migrating
Solaris Fortran programs to Linux.  Our research group has stuck with
running things in Solaris for as long as I know, now upgrading to a
Blade 2000 for $18 - $20K or a dual processor DELL with SMP under
Linux for under $10K has become a real issue.  I would like to go the
Linux route as hardware is much cheaper and easier to upgrade down the
road, as we do more runs we will have more data and buying SCSI disks
for PC's are a lot cheaper than for SUN's.  The code that we have
wouldn't really be optimized for the 64bit Blade archetechture nor do
we envision a complete rehaul to optimize it for parallel processing
at the moment.  However, SUN brings stability and error free
compilation at the moment, thus I am trying desparetly to port this
code to Linux and make a case for our Dell/Linux purchase.  I would
like to think that if this code runs sucessfully on the Linux PC we
buy now we may buy say 5 more PIII's and set up a Beowulf done the
road, and that would be an exciting venue for our computation
intensive modeling codes.

Any insight or potential pitfalls you could provide in our vision of
briging a fortran program from SUN arch. to Linux would be most
helpful.  I am actually surprised that there aren't more docs and
references on this subject as this might be a real lucrative method of
utilizing the cheap PC/LINUX platform, unless of course others know
what I don't yet.  The search continues...

Once again, thanks a bunch for your detailed response, its great to
find professional take valuable time out of their busy schedule to
help novices like myself.

Natham Simmons.

--0--

MAIN program:
  call ZEROFIELDS(MMAx,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

SUBROUTINE zerofields:
      subroutine ZEROFIELDS(Mmax,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

      integer mmax,npl,nz
      COMPLEX CXSZ(3,0:Mmax,-1:NPL+1,NZ),CXT(3,0:Mmax,-1:NPL+1,NZ)
      COMPLEX CPSZ(3,0:Mmax,0:NPL,NZ),CPS(3,0:Mmax,0:NPL,NZ)
      COMPLEX CXS(3,0:Mmax,0:NPL,NZ),CFI(3,0:mmax,0:NPL)

      do 203 k=0,Mmax
        DO 203 i=k,k+mmax
          DO j=1,3
            CFI(j,k,i)=CMPLX(0.,0.)
          enddo
          DO 203 j=1,NZ
            CPS(l,k,i,j)=CMPLX(0.,0.)
            CXS(l,k,i,j)=CMPLX(0.,0.)
            DO 203 l=1,3
              CXSZ(l,k,i,j)=CMPLX(0.,0.)
              CXT(l,k,i,j)=CMPLX(0.,0.)
              CPSZ(l,k,i,j)=CMPLX(0.,0.)
 203  CONTINUE
      return
      end
~



Tue, 04 Oct 2005 13:13:06 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux
[...]

Quote:
>       subroutine ZEROFIELDS(Mmax,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

>       integer mmax,npl,nz
>       COMPLEX CXSZ(3,0:Mmax,-1:NPL+1,NZ),CXT(3,0:Mmax,-1:NPL+1,NZ)
>       COMPLEX CPSZ(3,0:Mmax,0:NPL,NZ),CPS(3,0:Mmax,0:NPL,NZ)
>       COMPLEX CXS(3,0:Mmax,0:NPL,NZ),CFI(3,0:mmax,0:NPL)

>       do 203 k=0,Mmax
>         DO 203 i=k,k+mmax
>           DO j=1,3
>             CFI(j,k,i)=CMPLX(0.,0.)
>           enddo
>           DO 203 j=1,NZ

Do you suppose that your problem has anything to do with the fact that
variable l is uninitialized the first time the following two lines are
reached?  I thought at first that those might be numeral 1s, but a bit
of fiddling with my fonts convinced me that they are indeed letter ls.

Quote:
>             CPS(l,k,i,j)=CMPLX(0.,0.)
>             CXS(l,k,i,j)=CMPLX(0.,0.)
>             DO 203 l=1,3
>               CXSZ(l,k,i,j)=CMPLX(0.,0.)
>               CXT(l,k,i,j)=CMPLX(0.,0.)
>               CPSZ(l,k,i,j)=CMPLX(0.,0.)
>  203  CONTINUE
>       return
>       end

Indexing an array with an uninitialized variable is precisely one of the
kinds of things prone to producing segmentation faults.  Moreover, I
daresay that the fact that this wasn't segfaulting on Solaris doesn't
necessarilly mean that it was doing the right thing.  If it was, then I
would guess that you were the lucky beneficiary of a fortunate layout of
your arrays in memory (so that the errant initialization didn't trounce
anything important) and of automatic initialization-to-zero semantics.

John Bollinger



Tue, 04 Oct 2005 22:45:12 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux


Quote:
> MAIN program:
>   call ZEROFIELDS(MMAx,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

Out of curiosity, what are the values of mmax, npl, and NZ?  Not all
systems handle really huge arrays gracefully.

Quote:

> SUBROUTINE zerofields:
>       subroutine ZEROFIELDS(Mmax,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

>       integer mmax,npl,nz
>       COMPLEX CXSZ(3,0:Mmax,-1:NPL+1,NZ),CXT(3,0:Mmax,-1:NPL+1,NZ)
>       COMPLEX CPSZ(3,0:Mmax,0:NPL,NZ),CPS(3,0:Mmax,0:NPL,NZ)
>       COMPLEX CXS(3,0:Mmax,0:NPL,NZ),CFI(3,0:mmax,0:NPL)

>       do 203 k=0,Mmax
>         DO 203 i=k,k+mmax
>           DO j=1,3
>             CFI(j,k,i)=CMPLX(0.,0.)

Do you have a way of assuring that NZ is never defined to be less than
(2 * mmax)?

Quote:
>           enddo
>           DO 203 j=1,NZ
>             CPS(l,k,i,j)=CMPLX(0.,0.)

'l' hasn't been initialized at this point;  some compilers will
initialize it to zero, but others won't.  Are you sure CPS and CXS
shouldn't be initialized in this next loop?

Quote:
>             CXS(l,k,i,j)=CMPLX(0.,0.)
>             DO 203 l=1,3
>               CXSZ(l,k,i,j)=CMPLX(0.,0.)
>               CXT(l,k,i,j)=CMPLX(0.,0.)
>               CPSZ(l,k,i,j)=CMPLX(0.,0.)
>  203  CONTINUE
>       return
>       end
> ~

Louis Krupp


Tue, 04 Oct 2005 23:00:39 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:



> > > on the Sun machine initilizing declared variables in a subroutine
> > > prior to program execution doesn't cause any problems but it does with
> > > Linux.

> > There is certainly nothing wrong with "initilizing declared variables
> > in a subroutine prior to program execution"....

[code elided]

Oh.  Your terminology confused me.  When you said that initializing
causes problems, I assumed that you meant "initializing" as known to
the compiler.  That's what most of my reply addressed.  You aren't
doing that.  Your code doesn't have anything that the compiler would
see as particularly unique to initialization.  That the error might
occur in this code I could believe.  It is your categorization of this
as the compiler having trouble with initializing that threw me off.
Just because this code is the initialization step of your algorithm
doesn't mean that the compiler has trouble with initializing - that's
just not a helpful observation for debugging.  This subroutine has
DO loops; that doesn't mean that the compiler has trouble with DO
loops.  (Added later.  Hmm.  See below.  I just randomly made up
that example, but it is actually sort of related.  I do think the
problem is at least related to DO loops).

I don't, at a quick glance, see anything wrong with the subroutine,
but you haven't shown *NEARLY* enough for me to really tell.  I don't
see the context of the call - in particular the declarations of the
arguments.  Argument mismatches are a *MAJOR* source of often subtle
bugs in f77 code; it matters a lot.  Actually, I'd probably guess
that isn't the problem - just because it probably wouldn't have worked
on the Sun either.

Um....Say....  My first glance was just a little *TOO* quick.  I
skimmed pretty quickly and failed to actually check line-by-line and
dimension by dimension.  On looking again, I do see a problem....quite
possibly *THE* problem.

Afraid that I don't have good answers to your more generic questions.
Just the motherhood and apple pie kind of stuff like sticking reasonably
close to the standard, though I don't see any big problems in that
regard in your particular code.  Perhaps the one general piece of advice
that does seem to apply is that it can help to try out codes on
multiple systems because sometimes that can uncover problems that
you really do want to find, but that weren't obvious on one particular
compiler, such as...
...

Quote:
>             CPS(l,k,i,j)=CMPLX(0.,0.)
>             CXS(l,k,i,j)=CMPLX(0.,0.)
>             DO 203 l=1,3
>               CXSZ(l,k,i,j)=CMPLX(0.,0.)

....

Note that the first 2 lines above reference the variable "l"
*BEFORE* it is defined.  You probably want those 2 lines
inside of the "l" loop instead of outside.

This isn't really a Sun vs Linux question.  Its just a bug,
whose symptoms show up differently in different environments.
Bugs sometimes do that, particularly bugs that involve undefined
variables and array bounds.

On the first pass through those lines, "l" is undefined.  Perhaps
on the Linux box it was random garbage, causing your segfault.
There's a reasonable chance that on the Sun it started at 0.
Starting at 0 might have prevented a segfault, but it isn't good.
That's outside of the array bounds, so you probably overwrote
something - who knows what.  And after the first pass through,
l will have been left at 4 on exit from the "l" loop, so you'll
be out of bounds at the other end.

Did you have array bounds checking turned on?  That's a very
useful debugging aid.  It should have caught this one.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Tue, 04 Oct 2005 23:17:41 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux


(big snip)

Quote:
> ...
> >             CPS(l,k,i,j)=CMPLX(0.,0.)
> >             CXS(l,k,i,j)=CMPLX(0.,0.)
> >             DO 203 l=1,3
> >               CXSZ(l,k,i,j)=CMPLX(0.,0.)
> ....

> Note that the first 2 lines above reference the variable "l"
> *BEFORE* it is defined.  You probably want those 2 lines
> inside of the "l" loop instead of outside.

> This isn't really a Sun vs Linux question.  Its just a bug,
> whose symptoms show up differently in different environments.
> Bugs sometimes do that, particularly bugs that involve undefined
> variables and array bounds.

> On the first pass through those lines, "l" is undefined.  Perhaps
> on the Linux box it was random garbage, causing your segfault.
> There's a reasonable chance that on the Sun it started at 0.
> Starting at 0 might have prevented a segfault, but it isn't good.
> That's outside of the array bounds, so you probably overwrote
> something - who knows what.  And after the first pass through,
> l will have been left at 4 on exit from the "l" loop, so you'll
> be out of bounds at the other end.

Is that what Fortran says now?  In Fortran-66 the DO variable was considered
undefined after a DO loop, unless a GOTO or IF was used to leave the loop
early.  Many optimizing compilers would keep the DO variable in a register
and never store it in the actual variable.  Though I presume the reason for
the standard is that an early machine, with special index registers, left it
undefined.

-- glen



Tue, 04 Oct 2005 23:39:06 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:



> > And after the first pass through,
> > l will have been left at 4 on exit from the "l" loop, so you'll
> > be out of bounds at the other end.

> Is that what Fortran says now?  In Fortran-66 the DO variable was considered
> undefined after a DO loop, unless a GOTO or IF was used to leave the loop
> early.

Yes.  That changed in f77.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain



Tue, 04 Oct 2005 23:44:53 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:

> Dear Richard,

> Thanks for a detailed resonse to my inquiry.  You point out a few
> scenerios that I hadn't realized, which would prove important for
> general debugging.  My main concern is that the code functions
> perfectly well under Solaris 2.8, there are no issues or porblems.
> The initilized variables are 4 dimensional complex numbers passed to a
> subroutine that initilizes each element to a value CMPLX(0.,0.).  They
> aren't in a COMMON blocks, they are defined as
> COMPLEX CXS(3,0:Mmax,0:NPL,NZ),CFI(3,0:mmax,0:NPL) both in the main
> program and in the subroutine and all the dependent varibles are also
> defined.

Just fyi, using the term "initialisation" can mean a specific thing when talking about
fortran programs. I think of initialisation of a variable in a fortran program when you
assign a value to a variable in its type decalration statement, e.g.

  integer :: myint = 0

If this is in a subroutine/function then the variable myint is "initialised" to 0 *but
only on the first call to said sub/func*. Initialising a variable like above implies that
the variable has the SAVE attribute, i.e.

  integer, save :: myint = 0

which means the variable retains whatever value it had upon exit of the sub/func for the
next call to it. (does that sentence make sense?)

If you do something like

  integer :: myint
  myint = 0

i.e. using an assignment statement, I call this "resetting" a variable. This is just my
personal terminology - others may call it something else (including "initialisation"). I
use the term reset to distinguish it from the specific action of initialisation.

Quote:

> My compilation and execution works without a flaw in Solaris but Linux
> causes these problems.  What is the SAVE method, do I need to
> implement this with g77 for it to do what was already done without the
> SAVE command on Solaris?

Well, don't blame Linux. Blame the source code. It sounds like whoever wrote the code used
Fortran extensions that happened to be supported by the Sun platform compiler but not the
Linux platform compiler (this means that the Sun compilermay _not_ support these features
in future compiler releases since they're not standard. Unlikely, but it could happen).
Given the level of competition in the hardware market nowadays  people change platforms
about as often as their underpants so I, personally, think it's _very_ important to either
a) write -- and test! -- portable code, or b) document the bejesus out of the platform
specific parts of the code and make sure they are completely isolated from the rest of the
code, e.g. platform specific calls within your own wrapper subs/funcs. There are cases
where neither of these are doable for a number of reasons, but if you can do these things
it will save you this sort of headache when you port the code to an SGI or IBM, say.

Quote:
> By the way would you have any references for information in migrating
> Solaris Fortran programs to Linux.

One suggestion on this porting business is to determine if your compiler (Sun or linux)
has a switch that forces strict conformance to the fortran standard. This will highlight
any code that may be causing problems. Like I said before, there is nothing specific about
linux that is causing this problem - it's the code. I develop f90 code on a linux system,
but I test it on Suns, SGIs, IBMs, and other folks run it on HPs and PCs under Windows
(using C/DVF). I'm also in the process of buying another f90 compiler for my linux system
so I'll have an extra test case.

Quote:
> However, SUN brings stability and error free
> compilation at the moment, thus I am trying desparetly to port this
> code to Linux and make a case for our Dell/Linux purchase.

Given the problems you are having, I would look askance at the "error free" stats of your
Sun-based runs. The results may look right, but they may also be subtly incorrect since
you are/may be relying on peculiarities/idiosyncracies of how the Sun compiler does
things.

cheers,

paulv

--
Paul van Delst

Ph: (301)763-8000 x7748
Fax:(301)763-8545



Wed, 05 Oct 2005 01:43:11 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux


Quote:
>       do 203 k=0,Mmax
>         DO 203 i=k,k+mmax
>           DO j=1,3
>             CFI(j,k,i)=CMPLX(0.,0.)
>           enddo
>           DO 203 j=1,NZ
>             CPS(l,k,i,j)=CMPLX(0.,0.)
>             CXS(l,k,i,j)=CMPLX(0.,0.)
>             DO 203 l=1,3
>               CXSZ(l,k,i,j)=CMPLX(0.,0.)
>               CXT(l,k,i,j)=CMPLX(0.,0.)
>               CPSZ(l,k,i,j)=CMPLX(0.,0.)
>  203  CONTINUE

        Others have pointed out the problems of the uninitialised L in your
secondmost-inner loop.  I just want to say that I would caution against
intermingling the two styles of DO loops;  I've never liked nested DO
loops with the same labelled CONTINUE statement anyway...  I'd also
recommend moving to an F90/95 compiler with whole-array syntax as soon
as possible, to avoid these ugly and error-prone initialisation loops.

--

        KotPT -- "for stupidity above and beyond the call of duty".



Wed, 05 Oct 2005 02:30:22 GMT  
 Segmentation Fault: When attempting to run Sun Fortran code on Linux

Quote:

>MAIN program:
>  call ZEROFIELDS(MMAx,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

>SUBROUTINE zerofields:
>      subroutine ZEROFIELDS(Mmax,npl,NZ,CXSZ,CXT,CPSZ,CPS,CXS,CFI)

>      integer mmax,npl,nz
>      COMPLEX CXSZ(3,0:Mmax,-1:NPL+1,NZ),CXT(3,0:Mmax,-1:NPL+1,NZ)
>      COMPLEX CPSZ(3,0:Mmax,0:NPL,NZ),CPS(3,0:Mmax,0:NPL,NZ)
>      COMPLEX CXS(3,0:Mmax,0:NPL,NZ),CFI(3,0:mmax,0:NPL)

>      do 203 k=0,Mmax
>        DO 203 i=k,k+mmax
>          DO j=1,3
>            CFI(j,k,i)=CMPLX(0.,0.)
>          enddo
>          DO 203 j=1,NZ
>            CPS(l,k,i,j)=CMPLX(0.,0.)
>            CXS(l,k,i,j)=CMPLX(0.,0.)
>            DO 203 l=1,3
>              CXSZ(l,k,i,j)=CMPLX(0.,0.)
>              CXT(l,k,i,j)=CMPLX(0.,0.)
>              CPSZ(l,k,i,j)=CMPLX(0.,0.)
> 203  CONTINUE
>      return
>      end

BTW, you can just say, for example,

        CFI(j,k,i)=(0.,0.)

No need to invoke the CMPLX intrinsic.  The above is standard Fortran-77
(also 90, 95, etc).

Andy



Wed, 05 Oct 2005 04:30:54 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Segmentation fault --attempt to modify constant.

2. bug Ada Verdix SUN : segmentation fault at compil time

3. bug Ada Verdix SUN : segmentation fault at compil time

4. how to find segmentation fault problem with Sun f90

5. Segmentation Fault on SUN Ultra1,OK on HP and DEC

6. Sun F90 segmentation fault

7. Segmentation fault in POPLOG Linux.

8. IBM Orexx for Linux and Segmentation faults

9. - regina rexx - linux segmentation fault

10. reasons for segmentation faults on linux

11. Segmentation Fault using Ada IO under Linux

12. Character output yields segmentation fault under Linux

 

 
Powered by phpBB® Forum Software