segfault on array deallocation

[shane_stafford]

I get an inconsistent segmentation faultwhen deallocating a set of arrays with the deallocate statement, even when using the STAT variable. The program often exits normally, but occasionally, with no change of parameters, the program exits with a segmentation fault. The process then has to be killed with signal 9.

Unfortunately, this is not just a problem with ifort for Linux. This also occurs with Compaq Fortran on Win2k, although it occurs every time on Win2k.

My question is this: is it necessary to explicitly deallocate the arrays? This is a once-through code... the arrays are allocated at the beginning of the program after a few input parameters are read, then the numerical portion of the code runs to completion, then the arrays are deallocated at the last line of the program. Theonly reason the arrays are allocatable is to save memory and to facilitate efficient intrinsic array function use.

With this use of dynamic allocation, is it necessary to deallocate, or will the OS reclaim the allocated memory after the program exits?

[Steven_L_Intel1]

The OS will reclaim the space when the program exits. But the symptom you describe hints at data corruption in your program that could be giving bad results. It would be worthwhile for you to see if you can track this down.

[shane_stafford]

Thanks for the help.

Can you give some hints as to what kind of data corruption I shouldlook for? There is only one allocation call, one deallocation call, and no pointer usage. I do not understand why the deallocation does not just set STAT to some error value.

[Steven_L_Intel1]

It would be storing outside the bounds of the allocated array - usually at lower addresses. The problem is that the RTL's internal data structures have become corrupted. The STAT return is if the RTL can detect a problem (such as "this wasn't allocated"), but for performance reasons, there's no careful probing of addresses to protect against segfaults.

[shane_stafford]

I may have found the problem. There was a subroutine with 4 arguments that was passed as an argument to another subroutine which called the first sub with 6 args instead of 4:

subroutine sub1( a, b, c, d )

end subroutine sub1

subroutine sub2( extsub, extsubarg1, extsubarg2 )

call extsub(x1, x2, x3, x4, extsubarg1, extsubarg2)

end subroutien sub2

program foo

external sub1

call sub2( sub1, y1, y2 )

end program foo

So if I understand what you said, the actual argument references, y1 and y2, were passed through to sub1, where they must have overwritten and corrupted some data since there were no corresponding dummy arguments in sub1.

Since I have fixed this issue, the problem has not appeared again. Thanks very much for the pointers.

[Steven_L_Intel1]

Yep - that can certainly do it. I highly recommend the use of explicit interfaces (ideally module procedures, but if nothing else, INTERFACE blocks) to catch this sort of error.

Glad to hear that you got it sorted out.

[greetings8182]

I just noticed your post and I think I am having the same problem that you have but I have yet to solve it.

My code is as follow

subroutine case1 (A,B,1,2,3,4,5,6,7)
end

subroutine case2 (A,C,1,2,3,4,5,6,7)
end

subroutine case3(B,C,D,1,2)
end

subroutine case4(A,D,1,2,3,4,5,6,7)
(allocate(B))
(allocate(C))

call case1(A,B,1,2,3,4,5,6,7)
call case2(A,C,1,2,3,4,5,6,7)
call case3(B,C,D,1,2)

(deallocate(B))
(deallocate(C))
end

The problem comes round the end of the deallocate statement at the end.

I have used this structure before without any problem until now and I was sure that it worked when I first wrote it but the following day I had this problem.

thanks a lot in advance.

Isla.