Michael wrote:
> On May 1, 9:28 am, Michael <mwpowel...@[EMAIL PROTECTED]
> wrote:
>
> With some additional debug info turned on, this is what we get,
>
> forrtl: severe (157): Program Exception - access violation
> Image PC Routine Line Source
> ntdll.dll 7C911E58 Unknown Unknown Unknown
> ntdll.dll 7C918251 Unknown Unknown Unknown
> ntdll.dll 7C911C76 Unknown Unknown Unknown
> lodi.exe 00AC0716 Unknown Unknown Unknown
> lodi.exe 00A55481 Unknown Unknown Unknown
> lodi.exe 0056AFB0 _GRIDS_mp_ALLOCAT 283 grids.f90
> lodi.exe 0056CCF2 _GRIDS_mp_READ_GR 569 grids.f90
> lodi.exe 007950E7 _LODI_MOD_mp_LODI 4013
> lodi_mod.f90
> lodi.exe 0093D879 _MAIN__ 39
> lodi_main.f90
> lodi.exe 00AF33DD Unknown Unknown Unknown
> lodi.exe 00AC02CB Unknown Unknown Unknown
> kernel32.dll 7C816FD7 Unknown Unknown Unknown
>
> I don't know if this is helpful in diagnosing the issue apart from
> what has already been traced in the known source code?
>
>> On May 1, 9:15 am, Michael <mwpowel...@[EMAIL PROTECTED]
> wrote:
>>
>> I tried /heap-arrays and /Fn options, and this is still yielding a
>> failing allocate result.
>>
>>
>>
>>> On Apr 30, 6:48 pm, Steve Lionel <steve.lio...@[EMAIL PROTECTED]
> wrote:
>>> Thanks. And yessir, even with /traceback (already on) and /
>>> check:pointer, still failing at run-time.
>>> Declared as an allocatable,
>>> if (not(allocated(grid_dat%zg))) then
>>> write(*, '(/1x, "ALLOCATE_GRID: grid coordinates, allocating
>>> grid_dat%zg")')
>>> allocate(grid_dat%zg(idim, jdim), stat = allocerr)
>>> if (allocerr /= 0) stop 3
>>> endif
>>> Or as a pointer,
>>> if (size(grid_dat%zg)==0) then
This probably isn't the problem, but you (probably) can't do this. The
only way that size(grid_dat%zg) would be zero is if you previously
allocated it to size zero or pointed it to something of size
zero. It doesn't start out with zero size, nor does deallocating
it give it a zero size. Also, pointers start out in an undefined
status. You can specifically initialize them, but my recollection
is that you didn't do that in the snippets you showed.
You could try default initialization for your pointers by
putting something like
real,pointer,whateverelse :: zg => null()
in you type definitions.
Then use the associated(grid_dat%zg), rather than size, to see
if the pointer is associated with something or not. Using default
initialization has the advantage that all of your type internal
pointers will start out in a known state.
It's an interesting op****tunity in Fortran that there is no
way to tell if a pointer is in an "undefined" state. You
just have to keep track and not reference it if it is in an
undefined state. If its status is defined, you can tell if
it is associated or not.
Dick Hendrickson
>>> write(*, '(/1x, "ALLOCATE_GRID: grid coordinates, allocating
>>> grid_dat%zg")')
>>> allocate(grid_dat%zg(idim, jdim), stat = allocerr)
>>> if (allocerr /= 0) stop 3
>>> endif
>>> Regardless, allocate is failing with the following command line
>>> feedback,
>>> forrtl: severe (157): Program Exception - access violation
>>> Image PC Routine Line Source
>>> ntdll.dll 7C911E58 Unknown Unknown Unknown
>>> ntdll.dll 7C918251 Unknown Unknown Unknown
>>> ntdll.dll 7C911C76 Unknown Unknown Unknown
>>> lodi.exe 00B1C521 Unknown Unknown Unknown
>>> Which has to do with something like RtlInitializeCriticalSection(),
>>> deep within NTDLL.DLL. Not especially productive (i.e. no resolution
>>> to the issue) here, however thanks all for the insight, really and
>>> truly. Next place to go appears to be into the Intel Fortran forums.
>>> That said, I can't say this doesn't have something to do with a
>>> programmatic issue elsewhere in the code. That's entirely possible
>>> (i.e. scientists having written the code before we inherited it).
>>> Nothing against scientists, mind you, but there's something to be said
>>> about a professional developer's awareness of memory management
>>> issues.
>>> Anywho... Neither here nor there, apart from the fact we've got to get
>>> through the consequences of said issues, of course...
>>>> Michael wrote:
>>>>> After taking out the stat from allocate, we get further, but we
still
>>>>> end up failing, same place in NTDLL.DLL.
>>>> No, you're failing in your application. Try adding /traceback to the
>>>> set of options, so you get more detailed information, and you might
also
>>>> try /check:pointer.
>>>> If you need more help, post in the Intel Fortran user forum or
contact
>>>> Intel sup****t (links below).
>>>> I am not aware of any bugs related to ALLOCATABLE in the version you
are
>>>> using.
>>>> --
>>>> Steve Lionel
>>>> Developer Products Division
>>>> Intel Cor****ation
>>>> Nashua, NH
>>>> For email address, replace "invalid" with "com"
>>>> User communities for Intel Software Development Products
>>>> http://softwareforums.intel.com/
>>>> Intel Fortran Sup****t
>>>> http://sup****t.intel.com/sup****t/performancetools/fortran
>>>> My Fortran blog
>>>> http://www.intel.com/software/drfortran-Hide
quoted text -
>>> - Show quoted text -- Hide quoted text -
>> - Show quoted text -
>
|
