Home > Archive > Fortran > July 2004 > Allocatable Array of Derived Type crashes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Allocatable Array of Derived Type crashes
|
|
| Matthias Möller 2004-07-14, 8:58 am |
| Hello,
I have the following problem. In one of my modules, I define the
following derived data type:
TYPE item
INTEGER(KIND=I32), DIMENSION(:), POINTER :: a,k
END TYPE item
SUBROUTINE init(m,n)
TYPE(item) :: m
INTEGER :: n
ALLOCATE(m%a(n),m%k(-2:n))
END SUBROUTINE init
SUBROUTINE drop(m)
TYPE(item) :: m
DEALLOCATE(myitem%a,myitem%k)
NULLIFY(myitem%a,myitem%k)
END SUBROUTINE drop
I make use of this type as follows:
TYPE(item), DIMENSION(:), ALLOCATABLE :: myitem
ALLOCATE(myitem(10))
DO i=1,10
CALL init(myitem(i))
END DO
! Do something more or less usefull with myitem ;-)
DO i=1,10
CALL drop(myitem(i))
END DO
DEALLOCATE(myitem)
The main procedure is performed many times. Unfortunately, the code
stops running with the following error message:
signal Segmentation fault at >*[(unknown), 0x3ff80213a68] stq
t5, 8(t6)
and a tstack in dbx yields:
Thread 0x3:
> 0 (unknown)() [0x3ff80213a68]
1 malloc(0x3, 0x3ffc0087fa8, 0x3ff81a9f3f4, 0x28, 0x144ee9290)
[0x3ff800d68a4]
2 for_allocate(0x144ee9290, 0x2, 0x1200321b4, 0x144ee9270,
0x144ee9270) [0x3ff81a9f3f0]
3 $afc_list$ti32list_init(L = (...), N = 10, IFAC = 1.500000, IORD =
3) ["afc_list.f90":249, 0x1200321b0]
4 REFINE_1TO3(IEL = 219) ["afc_grid.f90":982, 0x12001bae8]
5 $afc_grid$grid_refine(IEL = [bad address (0x0)], IEL = [bad
address (0x0)], IEL = [bad address (0x0)], I1 = [bad address (0x2)], I2
= 1, E1 = [bad address (0x4)], IVT = [bad address (0x1081a1b00a030901)],
I1 = [bad address (0x0)], I2 = 962, IPOS1 = [bad address (0x4)], IPOS2 =
[bad address (0x1081a1b00a030902)], I1 = [bad address (0x0)], I2 = 962,
IPOS1 = [bad address (0x4)], IPOS2 = [bad address (0x1081a1b00a030902)],
I1 = [bad address (0x808)], I2 = 1701669204, I3 = [bad address (0x2d)],
E1 = [bad address (0x3fb17d6b00000002)], E2 = [bad address (0xdb)], E3 =
1818851104, IPOS = 2056, I1 = [bad address (0x100000808)], I2 = 2056, I3
= [bad address (0x1)], E1 = 1155517440, E2 = [bad address
(0x100000808)], E3 = 2097152, DA = (...), I = [bad address
(0x100000808)], OP = 0, I1 = [bad address (0x1081a1b00a030902)], I2 =
[bad address (0x1)], ALPHA = [bad address (0x90)]) ["afc_grid.f90":393,
0x120025a7c]
6 afc2d() ["afc_main.f90":55, 0x120036690]
7 main() ["for_main.c":203, 0x12005d51c]
This crash can be reproduced (with identical output), so I do not think,
it's a hardware problem.
Here is my hardware/software description:
uname -a
OSF1 XXXXXXXX V5.1 2650 alpha
f95 -version
Compaq Fortran X5.4A-1684
Compaq Fortran Compiler X5.4A-1684-46B5P
Many thanks for your help in advance,
Matthias
| |
| Ian Bush 2004-07-14, 8:58 am |
|
Hi Matthias
Matthias Möller wrote:
> Hello,
>
> I have the following problem. In one of my modules, I define the
> following derived data type:
>
Snip code.
>
> The main procedure is performed many times. Unfortunately, the code
> stops running with the following error message:
> signal Segmentation fault at >*[(unknown), 0x3ff80213a68] stq
> t5, 8(t6)
>
> and a tstack in dbx yields:
>
> Thread 0x3:
> 1 malloc(0x3, 0x3ffc0087fa8, 0x3ff81a9f3f4, 0x28, 0x144ee9290)
> [0x3ff800d68a4]
> 2 for_allocate(0x144ee9290, 0x2, 0x1200321b4, 0x144ee9270,
> 0x144ee9270) [0x3ff81a9f3f0]
> 3 $afc_list$ti32list_init(L = (...), N = 10, IFAC = 1.500000, IORD =
> 3) ["afc_list.f90":249, 0x1200321b0]
> 4 REFINE_1TO3(IEL = 219) ["afc_grid.f90":982, 0x12001bae8]
> 5 $afc_grid$grid_refine(IEL = [bad address (0x0)], IEL = [bad
> address (0x0)], IEL = [bad address (0x0)], I1 = [bad address (0x2)], I2
> = 1, E1 = [bad address (0x4)], IVT = [bad address (0x1081a1b00a030901)],
> I1 = [bad address (0x0)], I2 = 962, IPOS1 = [bad address (0x4)], IPOS2 =
> [bad address (0x1081a1b00a030902)], I1 = [bad address (0x0)], I2 = 962,
> IPOS1 = [bad address (0x4)], IPOS2 = [bad address (0x1081a1b00a030902)],
> I1 = [bad address (0x808)], I2 = 1701669204, I3 = [bad address (0x2d)],
> E1 = [bad address (0x3fb17d6b00000002)], E2 = [bad address (0xdb)], E3 =
> 1818851104, IPOS = 2056, I1 = [bad address (0x100000808)], I2 = 2056, I3
> = [bad address (0x1)], E1 = 1155517440, E2 = [bad address
> (0x100000808)], E3 = 2097152, DA = (...), I = [bad address
> (0x100000808)], OP = 0, I1 = [bad address (0x1081a1b00a030902)], I2 =
> [bad address (0x1)], ALPHA = [bad address (0x90)]) ["afc_grid.f90":393,
> 0x120025a7c]
> 6 afc2d() ["afc_main.f90":55, 0x120036690]
> 7 main() ["for_main.c":203, 0x12005d51c]
>
In my experience the most likely cause for this is that somehow you have
written to an area of memory you shouldn't have done, so corrupting something
to do with malloc. Have you compiled and run with array bounds checking on ?
Ian
| |
| Matthias Möller 2004-07-14, 8:58 am |
| Hi Ian,
> In my experience the most likely cause for this is that somehow you have
> written to an area of memory you shouldn't have done, so corrupting something
> to do with malloc. Have you compiled and run with array bounds checking on ?
Thank you for your hint. I have found the point. The search path of an
AVL tree was too short by one item ;-)
On the other hand I found out, that our fortran compiler is not able the
perform -check_bounds on all of my source files ;-(
Matthias
|
|
|
|
|