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
On 19 dec, 08:03, yairsuari <yairsu...@gmail.com> wrote:
> 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
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.
> On 19 dec, 08:03, yairsuari <yairsu...@gmail.com> wrote:
> > 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
> 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.
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,
yairsuari wrote: > 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
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.
<ianbush.throwaway.acco...@googlemail.com> wrote: > On 19 Dec, 08:03, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> > On 19 dec, 08:03, yairsuari <yairsu...@gmail.com> wrote:
> > > 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
> > 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.
> 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
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
> 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)
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.
