CODEWITHSUNDEEP
segmentation-faultfortran90bisection
Debanjan Basu
Debanjan Basu

Reputation: 894

Segmentation Fault - fortran 90 - bisection subroutine

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.

Upvotes: 0

Views: 922

Answers (1)

IanH
IanH

Reputation: 21431

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.

Upvotes: 2

Related Questions