looking for a strategy with segmentation fault

yairsuari

unread,

Dec 19, 2008, 2:03:42 AM12/19/08

to

my program crashes after some 30 min running with a segmentation
fault.
the line it flies in is definately not an array over bounds i also
check this by the compiler with ifort "-check "all.
it took me ages to find out what the problem was because i could not
use a debugger and when i tried print debugging the line where it
happened seemed to be moving around currently the program crashes
here:
write(6,*)'line 939 size dum',size(dum)
my question is:
is there a known way to find out the cause of this problem and more
specifically who owns this memory adress, if it exists and who was the
last process to write there? (i have to use the intel debugger since
this is a module)
thanks for any help

Arjen Markus

unread,

Dec 19, 2008, 3:03:36 AM12/19/08

to

There are no foolproof receipes for situations like this. But I would
advise you to try it with another compiler. Chances are the program
will crash in a different way and that may help pinpoint the
underlying
cause.

Other things you can try (if you do not already) is:
- Use "implicit none" in every module and separate subprogram
- Put everything in a module to make sure the interfaces can be
checked
- Tools like valgrind or strace may help to tackle the problem

As the problem moves around when you introduce write statements, it is
likely to be an array bound violation or a pointer problem. Are you
using pointers in your program? That is one thing to watch out for:
deallocated memory that you still refer to.

Regards,

Arjen

Ian Bush

unread,

Dec 19, 2008, 3:43:08 AM12/19/08

to

I want to second Arjen's recommendations ( an argument mismatch
would be my bet, possibly caused by implicit typing ) , but would
also like to add that if all possible you should get a debugger
on any system that you develop on. I realize it might not be your
decision, but really the amount of effort that can be save by having
one makes it well worthwhile,

Ian

Craig Powers

unread,

Dec 19, 2008, 2:09:50 PM12/19/08

to

I would strongly recommend double-checking procedure interfaces. The
ifort -check all option takes care of bounds checks (and, depending on
the compiler version, uninitialized variable access), but it does not do
checking on implicit interfaces. That's the most likely source of
trashing memory that wouldn't be caught by the bounds checks.

yairsuari

unread,

Dec 20, 2008, 12:52:42 AM12/20/08

to

On Dec 19, 12:43 am, Ian Bush

I do have a debugger, it just took me more then a month to use it on a
module(sorry for being unclear).
just a small question what is an implicit typing?
thanks for the help
yair

user1

unread,

Dec 21, 2008, 7:48:16 PM12/21/08

to

yairsuari wrote:

[snip]

> just a small question what is an implicit typing?
> thanks for the help
> yair

It's based on first letter of variable name. A-H and O-Z default to real, I-N
are integer.

Therefore, God is real, unless declared integer, logical, character ;-)

robin

unread,

Dec 28, 2008, 7:26:08 PM12/28/08

to

"yairsuari" <yair...@gmail.com> wrote in message
news:b29757de-5e61-47c6...@f40g2000pri.googlegroups.com...

Your query is like "My car won't start; what's wrong with it?"

You need to post at least one subroutine,
and to tell us how you have interfaced it.