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 caused by write(6,*)


Hi,

My program generate "Segmentation fault". Trying to find reason I
found out that this prob;em disappears if I comment a line which
performs output on the screen. I looks really strange. Does anybody
know why it can happens?

Kurda Yon <kurda@yahoo.com> wrote:
> My program generate "Segmentation fault". Trying to find reason I
> found out that this prob;em disappears if I comment a line which
> performs output on the screen. I looks really strange. Does anybody
> know why it can happens?

Almost an infinite number of reasons. The first thing to realize is that
just because the problem went away when you commented out that line,
that does *NOT* mean the problem is in that line. It has at least
reasonable odds that the problem is in a completely unrelated part of
the code and that commenting out that line just moved code around in
memory in such a way that the symptoms of the problem disappeared.

"Segmentation fault" is Unix-speak for memory addressing problems.
(That's an approximate translation, but close enough). It can be caused
by lots of things. High on the list are exceeding array bounds (do you
have bounds checking turned on?) and mismatched argument lists.

Because it is generally related to memory addressing problems, it is
quite common for the symptoms to change if memory addresses change,
which can be caused by trivial changes in completely unrelated parts of
the code.

It is at least vaguely possible that you don't have screen output set up
properly. Usually one doesn't have to do anything much special, but
there are environments where a screen output device isn't defined by
default. You didn't mention anything at all about your environment, so I
can't guess whether you would be in such a situation. If other screen
output works, then that's probably not it.

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

On May 22, 3:40 pm, Kurda Yon <kurda@yahoo.com> wrote:

> Hi,

> My program generate "Segmentation fault". Trying to find reason I
> found out that this prob;em disappears if I comment a line which
> performs output on the screen. I looks really strange. Does anybody
> know why it can happens?

I'd only add if this is the same program as the one w/ the problem in
an apparently corrupt array in a function/subroutine that Richard's
hypothesis of an indexing error is even higher on the list of likely
candidates.

Be sure to read the documentation for the compiler to find out how to
compile with bounds checking on to catch bounds errors when they occur
at run time while debugging/writing new code.  Will save untold hours
of hunting down problems similar to those you've posted about
otherwise.

On 22 May, 21:40, Kurda Yon <kurda@yahoo.com> wrote:

> Hi,

> My program generate "Segmentation fault". Trying to find reason I
> found out that this prob;em disappears if I comment a line which
> performs output on the screen. I looks really strange. Does anybody
> know why it can happens?

I'm not sure, but is using "write(6,*)" to write to standard output
non-portable? Is it better practice to use "write(*,*)"? Still...
using write(6,*) on my system works fine without any segmentation
fault - so I know I may not be helping.

Michal.

Nym <neverwillre@gmail.com> wrote:
> I'm not sure, but is using "write(6,*)" to write to standard output
> non-portable? Is it better practice to use "write(*,*)"? Still...
> using write(6,*) on my system works fine without any segmentation
> fault - so I know I may not be helping.

That's a messy area finally at least helped by f2003. (It is messy
enough that it can't be completely solved without compatibility
problems, but at least it can be helped for future codes).

No, using 6 as equivalent to * isn't strictly portable. First, the
number 6 is non-portable, although that's the right number for most
current compilers. Second, some compilers have fine points of
distinction between 6 and *. For example, there are compilers where both
6 and * appear to go to the same place in simple situations, but they
get separated if you do command-line redirection. I personally find that
behavior annoying, but other people like it.

There are big reasons to want to use a unit number in some codes. (Well,
a non-numeric handle would be better in my opinion, but the language
doesn't have that; that's an issue that has been proposed/discussed here
before). A major reason is that if you use a unit number, you can select
the appropriate file just by setting the value of the number. There are
many cases where you have some output that you might want to go either
to the screen or to some other file. With a unit number, you can just
do, for example

   subroutine sub(lun,...)
   ...
      write(lun, ...

and it will work in either case, given an appropriate lun. If you have
to use *, this turns into

   subroutine sub(lun,...)
   ...
     if (some_condition) then
       write (*, ...
    else
       write(lun,...

This can turn into a big pain. (You might need hundreds of such tests,
making the code a mess).

Unfortunately, as you note, there is no portable way to know an
appropriate unit number for the screen. F2003 adds such a way.

But... that was a bit of a side excursion. I doubt that is related to
the OP's problem. I won't 100% rule it out, but I'd guess against it. In
most implementations, if 6 isn't teh right number for standard output,
that would probably just result in writing to a file with a default name
like fort.6, or some such thing.

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

You have to say which compiler you are using and in what mode of use,
for what kind of computer, in order to get help. I also suggest you
supply a small section of the code around where you suspect you have a
problem although the real problem may be elsewhere.

Kurda Yon wrote:
> Hi,

> My program generate "Segmentation fault". Trying to find reason I
> found out that this prob;em disappears if I comment a line which
> performs output on the screen. I looks really strange. Does anybody
> know why it can happens?

I've got this problem on a fortran code with Intel fortran and -ipo
option set. I never found where was the bug in the code (and I spent a
lot of time on this problem!). The code was runing without this option
and on the same computer with all the compilers I can use and all
options cobination available! It was also runing on other server
(RS6000, NEC...)... with different compilers...

May be your compiler can also be wrong...

Patrick

Patrick Begou <Patrick.Be@hmg.inpg.fr> wrote:
> May be your compiler can also be wrong...

Of course, it may be. Examples come up here regularly. However, it is
far more common for people to mistakenly blame the compiler for errors
than for it to actualy be a compiler error. I've seen nothing here that
particularly suggests a compiler error. That doesn't mean it couldn't be
one, but on the whole, I think it a mistake to encourage users in that
direction without better evidence.

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

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