On May 1, 2:10=A0pm, Dick Hendrickson <dick.hendrick...@[EMAIL PROTECTED]
> wrote:
Great news! I searched the Intel forums (I recommend those, BTW, for
Intel / Microsoft users) and found a post having to do with allocate
access violations. Here I was directed to a set of Microsoft debugging
tools, among them gflags.exe, which puts a monitor on the page heap.
When this is enabled, we were immediately able to detect where in the
code we were having issues. I think this is the thing we were hoping
to find.
Hope this was of some help to others.
Thanks all!
> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0PC =A0 =A0 =A0 =A0Routine =A0 =A0 =A0
=
=A0 =A0 =A0Line =A0 =A0 =A0 =A0Source
> > ntdll.dll =A0 =A0 =A0 =A0 =A07C911E58 =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > ntdll.dll =A0 =A0 =A0 =A0 =A07C918251 =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > ntdll.dll =A0 =A0 =A0 =A0 =A07C911C76 =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > lodi.exe =A0 =A0 =A0 =A0 =A0 00AC0716 =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > lodi.exe =A0 =A0 =A0 =A0 =A0 00A55481 =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > lodi.exe =A0 =A0 =A0 =A0 =A0 0056AFB0 =A0_GRIDS_mp_ALLOCAT =A0 =A0 =A0
=
=A0 283 =A0grids.f90
> > lodi.exe =A0 =A0 =A0 =A0 =A0 0056CCF2 =A0_GRIDS_mp_READ_GR =A0 =A0 =A0
=
=A0 569 =A0grids.f90
> > lodi.exe =A0 =A0 =A0 =A0 =A0 007950E7 =A0_LODI_MOD_mp_LODI =A0 =A0 =A0
=
=A04013
> > lodi_mod.f90
> > lodi.exe =A0 =A0 =A0 =A0 =A0 0093D879 =A0_MAIN__ =A0 =A0 =A0 =A0 =A0
=A0=
=A0 =A0 =A0 =A039
> > lodi_main.f90
> > lodi.exe =A0 =A0 =A0 =A0 =A0 00AF33DD =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > lodi.exe =A0 =A0 =A0 =A0 =A0 00AC02CB =A0Unknown =A0 =A0 =A0 =A0 =A0
=A0=
=A0 Unknown =A0Unknown
> > kernel32.dll =A0 =A0 =A0 7C816FD7 =A0Unknown =A0 =A0 =A0 =A0 =A0 =A0
=A0=
Unknown =A0Unknown
>
> > 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,
> >>> =A0 =A0 =A0if (not(allocated(grid_dat%zg))) then
> >>> =A0 =A0 =A0 =A0 write(*, '(/1x, "ALLOCATE_GRID: grid coordinates,
allo=
cating
> >>> grid_dat%zg")')
> >>> =A0 =A0 =A0 =A0 allocate(grid_dat%zg(idim, jdim), stat =3D allocerr)
> >>> =A0 =A0 =A0 =A0 if (allocerr /=3D 0) stop 3
> >>> =A0 =A0 =A0endif
> >>> Or as a pointer,
> >>> =A0 =A0 =A0if (size(grid_dat%zg)=3D=3D0) then
>
> This probably isn't the problem, but you (probably) can't do this.
=A0The
> 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. =A0It doesn't start out with zero size, nor does deallocating
> it give it a zero size. =A0Also, pointers start out in an undefined
> status. =A0You 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
> =A0 =A0 =A0 =A0 =A0real,pointer,whateverelse =A0:: =A0zg =3D> 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. =A0Using 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. =A0You
> just have to keep track and not reference it if it is in an
> undefined state. =A0If its status is defined, you can tell if
> it is associated or not.
>
> Dick Hendrickson
>
>
>
> >>> =A0 =A0 =A0 =A0 write(*, '(/1x, "ALLOCATE_GRID: grid coordinates,
allo=
cating
> >>> grid_dat%zg")')
> >>> =A0 =A0 =A0 =A0 allocate(grid_dat%zg(idim, jdim), stat =3D allocerr)
> >>> =A0 =A0 =A0 =A0 if (allocerr /=3D 0) stop 3
> >>> =A0 =A0 =A0endif
> >>> Regardless, allocate is failing with the following command line
> >>> feedback,
> >>> forrtl: severe (157): Program Exception - access violation
> >>> Image =A0 =A0 =A0 =A0 =A0 =A0 =A0PC =A0 =A0 =A0 =A0Routine =A0 =A0
=A0=
=A0 =A0 =A0Line =A0 =A0 =A0 =A0Source
> >>> ntdll.dll =A0 =A0 =A0 =A0 =A07C911E58 =A0Unknown =A0 =A0 =A0 =A0 =A0
=
=A0 =A0 Unknown =A0Unknown
> >>> ntdll.dll =A0 =A0 =A0 =A0 =A07C918251 =A0Unknown =A0 =A0 =A0 =A0 =A0
=
=A0 =A0 Unknown =A0Unknown
> >>> ntdll.dll =A0 =A0 =A0 =A0 =A07C911C76 =A0Unknown =A0 =A0 =A0 =A0 =A0
=
=A0 =A0 Unknown =A0Unknown
> >>> lodi.exe =A0 =A0 =A0 =A0 =A0 00B1C521 =A0Unknown =A0 =A0 =A0 =A0 =A0
=
=A0 =A0 Unknown =A0Unknown
> >>> 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
stil=
l
> >>>>> end up failing, same place in NTDLL.DLL.
> >>>> No, you're failing in your application. =A0Try adding /traceback to
t=
he
> >>>> set of options, so you get more detailed information, and you might
a=
lso
> >>>> try /check:pointer.
> >>>> If you need more help, post in the Intel Fortran user forum or
contac=
t
> >>>> 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
> >>>> =A0 =A0http://softwareforums.intel.com/
> >>>> Intel Fortran Sup****t
> >>>> =A0 =A0http://sup****t.intel.com/sup****t/performancetools/fortran
> >>>> My Fortran blog
> >>>> =A0 =A0http://www.intel.com/software/drfortran-Hidequoted
text -
> >>> - Show quoted text -- Hide quoted text -
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
|
