Segmentation fault - invalid memory reference. Error

[zmth]

The following compiles ok with no error messages but gives

Segmentation fault - invalid memory reference. when run the executable

module inc
integer*1:: i,j,nps
integer*1,allocatable::ib)
type mixed ; integer*1,allocatable :: ib) ; real val ; end type mixed
type(mixed), allocatable :: dout)
contains
subroutine dd(dout,nps);integer*1:: i,j,nps; type(mixed) dout)
do i=1,size(dout) ;do j=1,3*nps;dout(i)%ib(j)=i/j;enddo;dout(i)%val=real(i)/j;enddo
end
end module inc
use inc
nps=3
allocate(ib(3*nps))
allocate(dout(2*nps**2))
call dd(dout,nps)
end

Why would one get this error ?

 

[mikrom]

Before posting a source, press the Preview button to see if your source will be posted properly.

Your "writing style" is very ugly and nobody could understand it. Say why are you using semicolons?

I reformatted your source and added write statements to see what it does :

module inc
 integer*1 :: i,j,nps
 integer*1,allocatable:: ib(:)
 type mixed 
   integer*1,allocatable :: ib(:)
   real val
 end type mixed
 type(mixed), allocatable :: dout(:)
 contains
 subroutine dd(dout,nps)
   integer*1:: i,j,nps
   type(mixed) dout(:)
   do i=1,size(dout)
     do j=1,3*nps
        dout(i)%ib(j)=i/j;
        write(*,*) 'dout(', i, ')%ib(', j,') = ', dout(i)%ib(j)
     end do
     dout(i)%val=real(i)/j
     write(*,*) 'dout(', i, ')%val = ', dout(i)%val
   enddo
 end subroutine
end module inc

program use_inc
  use inc
  nps=3
  allocate(ib(3*nps))
  allocate(dout(2*nps**2))
  call dd(dout,nps)
end program use_inc

And it runs without error and does some computation:

$ gfortran zmth2.f95 -o zmth2

$ zmth2
 dout(    1 )%ib(    1 ) =     1
 dout(    1 )%ib(    2 ) =     0
 dout(    1 )%ib(    3 ) =     0
 dout(    1 )%ib(    4 ) =     0
 dout(    1 )%ib(    5 ) =     0
 dout(    1 )%ib(    6 ) =     0
 dout(    1 )%ib(    7 ) =     0
 dout(    1 )%ib(    8 ) =     0
 dout(    1 )%ib(    9 ) =     0
 dout(    1 )%val =   0.100000001
 dout(    2 )%ib(    1 ) =     2
 dout(    2 )%ib(    2 ) =     1
 dout(    2 )%ib(    3 ) =     0
 dout(    2 )%ib(    4 ) =     0
 dout(    2 )%ib(    5 ) =     0
 dout(    2 )%ib(    6 ) =     0
 dout(    2 )%ib(    7 ) =     0
 dout(    2 )%ib(    8 ) =     0
 dout(    2 )%ib(    9 ) =     0
 dout(    2 )%val =   0.200000003
 dout(    3 )%ib(    1 ) =     3
 dout(    3 )%ib(    2 ) =     1
 dout(    3 )%ib(    3 ) =     1
...
...

 

[xwb]

I agree with mikrom: don't use semicolons because you can: only use it if there is a good reason.

It just works purely by chance in mikrom's case, possibly using default allocation. It is probably crashing because dout(i)%ib is not allocated

 

[salgerman]

Yeah, unfortunately, there are two allocatable ararys named "ib", one outside and another inside the type definition...the main program only allocates the one outside the type definition.

 

[mikrom]

I have overlooked it because i was concentrated on the formatting of zmth's source.

 

[xwb]

Wouldn't have spotted it if mikrom hadn't refomatted the code.

 

[zmth]

Yeah, unfortunately, there are two allocatable ararys named "ib", one outside and another inside the type definition...the main program only allocates the one outside the type definition

Yes I suspected it may not be allocating fully like perhaps I would have to allocate every
row like every i of ib(i) but then again hopefully the compiler would have figured all that out or given some compile error message. The using semi-colons vs without is really strange though. Seems like it could be coincidence. Probably best just to separate standard integer idout, and real rdout) arrays to be more straightforward rather than mixed derived type.

 

[zmth]

[Before posting a source, press the Preview button to see if your source will be posted properly.]

I can't figure out using that ' code ' icon how to put the code within that box rather than just an empty code box.

 

[salgerman]

You basically click on the icon and answer the question about the NAME of the language you are about to include code of. After saying ok, you will see two set of square brackets, one is the beginning tag, the second is the ending tag...you insert your code right in between.

I am afraid you missed my point earlier.

Just like you allocate any other allocatable array, you also need to allocate allocatable arrays inside type definitions regardless whether your type-def arrays are fixed length of allocatable. See code snippedt below:

allocate(ib(3*nps))
allocate(dout(2*nps**2))
do i=1, 2*nps**2
    allocate( dout%ib(3*nps) ) 
end do

Never mind the terrible idea of having two arrays named the same, one outside the type-def and another inside. But left them there so you can see the difference on how to allocate each.

 

[mikrom]

can't figure out using that ' code ' icon how to put the code within that box rather than just an empty code box

I wrote you here

http://www.tek-tips.com/viewthread.cfm?qid=1754852

at 12 Sep 15 21:19 that you should post your code between the code tags like here:

[red][pre]

[/pre][/b][/red][pre]...
module inc
 integer*1 :: i,j,nps
 integer*1,allocatable:: ib(:)
 type mixed
 ...
 ...[/pre]
[red][b][pre]

[/pre][/red]

For more info look here: TGML

Then press the [red]<Preview>[/red] button and look if the result is as you expected.
When everything is ok the press [red]<Submit Post>[/red] button.

 

[zmth]

allocate(ib(3*nps))
allocate(dout(2*nps**2))
do i=1, 2*nps**2
allocate( dout%ib(3*nps) )
end do

But what about the single real vaulue : val as in dout(i)%val which would actually be the 3*nps+1'th entry or column in row i ? (which is the reason for the mixed type in the first place) Should it take care of that automatically ? because of the original definition of the type mixed... in dout along with the

allocate(dout(2*nps**2)) ?

Also the fact that mikrom happenned to get the original program to work by taking out the semicolons and writing each statement on a different line was just coincidence there as i did the same,taking out semicolons, and still got segmentation fault at run time. It may well have run on his machine and disposition at that time written the original way with the semicolons - it should be compiled the same anyway regardless.

 

[salgerman]

The real variable 'val' is fine and readily usable as it is of known size; it is nicely allocated in every one of the dout().

As far as the program running or not running, I think is the luck of the draw; when things are not written correctly, things are just not guaranteed...sometimes they work, sometimes they don't in the same machine; or, sometimges they work in one machine and not the other; or work with one compiler and not another...or even when they appear to work, they are not quite working in that you are stepping out of boundaries of your own memmory or even if you stay within, you may be overwriting other stuff within your program, etc. Just not cool, period. At this time, artifial intelligence is not readily available to us; instead, with our silly laptops, we just have artifial stupidity at our disposal and, so, we need to tell the computer exactly what to do.

 

[zmth]

Using the code snippet:

allocate(ib(3*nps))
allocate(dout(2*nps**2))
do i=1, 2*nps**2
allocate( dout%ib(3*nps) )
end do

though DOES give compile error. The original was leaving out those last 3 lines - leaving out the do loop - which did not give compile error but got the segmentation error at run time. It may be just ' happenstance ' it ran on the machine of mikrom at that time etc. but I do wonder if he was using gfortran compiler with windows 7 or just what.

 

[salgerman]

Sorry, the lines should be (notice index to dout):

do i = 1, 2*nps**2
    allocate( dout(i)%ib(3*nps) )
end do

...but you or the compiler should have spotted that!