Segmentation Fault - fortran 90 - bisection subroutine

Question

program bisect
real(8) ::  output
call bisection(3.d0,4.d0,2.d0,output)
print*, output
end program bisect

subroutine bisection(a,b,error,result)
real(8):: a,b,error,c,result
logical:: proceed
  proceed = .true.
  do while (proceed)
  if (sin(a)*sin(b).lt. 0.d0) then
     c=(a+b)/2
     if (sin(a)*sin(c).lt.0.d0) then
        b=c
     else
        a=c
     end if
  else  
     stop 'cannot be bisected'
  end if 

  if (abs(a-b).lt. error) then
     proceed = .false.
  end if
 end do
 result= a
end subroutine bisection

A version of the same code is uploaded here.

This is the minimal example i could come up with. This yields a segmentation fault on running the executable with gfortran, and also on the website.

score 2 · Accepted Answer · answered Feb 11 '13 at 19:51

2

The dummy arguments a and b are associated with actual arguments that are constants. Constants are not definable - your program is trying to change the value of "3.0d0" or "4.0d0". If your program were to succeed then chaos would break out across the universe.

I strongly recommend:

Use module procedures. This allows the compiler to check that actual arguments are consistent with dummy arguments.
Use INTENT specifications on your dummy argument definitions. This allows the compiler to check that things that need to be modifiable are, and that things that may not be modified are not.

A workaround for your problem is to have appropriate variables in your main program that hold the initial values of 3.0d0 and 4.0d0, and pass those modifiable variables to your subroutine. Alternatively you could create temporary copies of the dummy arguments inside the subroutine. In F2003 the VALUE attribute can be used to do this automatically.

While we're at it - use IMPLICIT NONE in all scopes. Always.

answered Feb 11 '13 at 19:51

IanH

21,026
2
37
59

Doesn't the subroutine treat the arguments as variables? for example something similar would work in python. – Debanjan Basu Feb 12 '13 at 07:47
A compelling reason to prefer Fortran to Python. Any language which permits the assignment `4.0 = 3.5` is seriously broken. – High Performance Mark Feb 12 '13 at 12:01
@Mark: that is debatable at the least. if someone were to design a subroutine, which is supposed to be a reusable piece of code block; they better make it indifferent/agnostic to the way the arguments are fed in. Can you name even one benefit that comes out of Fortran's way of doing things? I do get your point about changing constant values, but that can be skirted around by not allowing literals for an argument with `intent(out)`. – Debanjan Basu Feb 13 '13 at 11:02
for clarity - python doesnt have subroutines at all. Python functions have arguments which do not have an intent type. – Debanjan Basu Feb 13 '13 at 11:24
The subroutine does treat the problematic dummy arguments as variables. That's the issue... they're not! Fortran's model of argument "passing" (in this case - being imprecise for the sake of brevity) is "as if" the dummy argument and actual argument referred to the same underlying thing. You are not just passing a value - a form of association is established between the dummy argument and the actual argument. (How the compiler actually implements things is a separate issue - it may pass a reference to the actual argument or perhaps pass values back and forth - a legal program cannot tell.) – IanH Feb 13 '13 at 20:27

Segmentation Fault - fortran 90 - bisection subroutine

1 Answers1