| View previous topic :: View next topic |
| Author |
Message |
jjgermis
Joined: 21 Jun 2006
Posts: 404
Location: N�rnberg, Germany
|
 Posted: Thu Jul 14, 2011 4:32 pm Post subject: unknown type 17 |
 |
|
In debug mode without executing any commands sdbg.exe reports the following message:
unknown type 17
What is the meaning of this warning? Later in the program the debugger report:
Error 416, Bad request for stack memory
Are the messages perhaps somehow related. The code I am trying was mainly developed using gfortran where it works without any problems.
Some advice or some hints will be really very helpful.
The first code lines are as follows:
| Code: |
program FEMP
use xml_data_assem_t
use FEMPtype
use FEMPutil
implicit none
integer :: void
type(file_type) :: fls
type(fpl_type) :: fpl
type(age_type) :: age
!
integer :: t,tn
double precision :: pi,slave_angle
interface
integer function fn_draw_polygons(fls)
use FEMPtype
type(file_type),intent(inout) :: fls
end function
end interface
interface
subroutine initial_mesh(fls,fpl)
use FEMPtype
implicit none
type(file_type),intent(in) :: fls
type(fpl_type),intent(out) :: fpl
end subroutine initial_mesh
end interface
interface
subroutine makeneigbors(fpl)
use FEMPtype
implicit none
type(fpl_type),intent(inout) :: fpl
end subroutine makeneigbors
end interface
interface
subroutine save_fpl(fls,fpl,dtheta,rr)
use FEMPtype
IMPLICIT NONE
type(file_type),intent(in) :: fls
type(fpl_type),intent(in) :: fpl
double precision,intent(in) :: dtheta,rr
end subroutine save_fpl
end interface
interface
subroutine bld_adp_all(fpl,t,tn)
use FEMPtype
implicit none
type(fpl_type),intent(inout) :: fpl
integer :: t,tn
end subroutine bld_adp_all
end interface |
|
|
| Back to top |
|
 |
jjgermis
Joined: 21 Jun 2006
Posts: 404
Location: N�rnberg, Germany
|
| Posted: Sat Jul 16, 2011 8:31 am Post subject: |
|
|
| This seems like a very unknown message. Not even Google has an answer to unknown type 17. This message occurs even before any line of code is executed. Therefore I conclude that the answer to this should be at Silverfrost. |
|
| Back to top |
|
|
Robert
Joined: 29 Nov 2006
Posts: 460
Location: Manchester
|
| Posted: Sun Jul 17, 2011 9:32 pm Post subject: |
|
|
Type 17 is unknown -- what more can be said 
Type 17 is actually 'array', so clearly shouldn't be unknown. Has it just started happening?
It shouldn't affect the running of your program, it is just the debugger getting a bit confused and it may not display a type element correctly. |
|
| Back to top |
|
|
jjgermis
Joined: 21 Jun 2006
Posts: 404
Location: N�rnberg, Germany
|
| Posted: Wed Aug 03, 2011 9:56 am Post subject: |
|
|
This seems to appear only when using derived types. However, until the bad request for stack memory the program runs fine.
It is a bit of an unsatisfying result since the debugger should help to detect errors in the code. In a previous thread the bebugger needed some debugging  . As long as it is possible to understand a message produced by the debugger the is no problem - then the message should at leat be in the help.
When working on Windows my preferred compiler is FTN95. However, on Linux we use gfortran. The code should be working with both compilers. This seems to be a problem some times. |
|
| Back to top |
|
|
jjgermis
Joined: 21 Jun 2006
Posts: 404
Location: N�rnberg, Germany
|
| Posted: Thu Aug 04, 2011 8:29 am Post subject: |
|
|
That is why I like FTN95 so much:
The exact same code runs without problems using gfortran. Compiling the code using FTN95 errors are detected! Writing "clean" code is much easier using FTN95. I have experience this in the past as well. Rearranging the code a bit and tracing the error with the debubbger the above mentioned messages are fixed as well.
I can only verify the results presented on http://www.polyhedron.com/pb05-win32-diagnose0html. However, when it comes to speed (very important for number cruching) FTN95 is slower than gfortran. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
