access violation during allocate()

[chuckhp]

I am having a weird problem while trying to compile a complex, mixed C/Fortran program and I haven't been able to figure it out yet. Maybe someone can help. I'm not sure if the problem is related to the mixture of C and Fortran projects or not. The problem is that at some point in my code, I have an allocate statement of the form:

allocate(sdata(length))

sdata is a local pointer in that subroutine declared as:

type(string_item), dimension(:), pointer :: sdata=>null()

the string_item type is declared in another module (included in the present one) as:

type :: string_item
character(len=1000) :: Value=""
character(len=1000) :: DefaultValue=""
character(len=1000) :: FormName=""
character(len=1000) :: Description=""
character(len=1000), dimension(:), pointer :: SelectList=>null()
end type string_item

The local variable 'length' has the value 1 in this particular case. The problem is that sometimes, not always, my program crashes at the allocate() command with the error message,

Unhandled exception at 0x7c91888f in VCESage.exe: 0xC0000005: Access violation reading location 0x21c66bd8.

The error appears to be occuring in ntdll.dll since the top of the call stack looks like this:

ntdll.dll!7c91888f()

The weird part is that if I run this with debugging by pressing F5 in IVF, it doesn't crash at all (it runs to completion with no errors), but if I run it without dubugging (Ctrl-F5), it encounters the error, at which point I can break into the code at that point. What's even weirder is that upon doing that, if I hover over the sdata symbol, it looks like it has been correctly allocated with length 1 and all of its data items have been initialized correctly. This leads me to believe that the call stack has been corrupted somehow during the allocate statement, maybe when it it trying to return to the main main program from the allocate command?

I understand that errors like this could be caused by trying to access arrays outside of their bounds, or trying to access unallocated pointers, and I have been trying to check through my code very carefully to make sure I am not doing that anywhere. I still may find something somehwere else, but it was just odd to me that this error was occuring within the allocate statement itself.

This particular subroutine is being called from a C program, but the arguments all have their correct values when entering this subroutine, so it didn't appear that there is any problem with the C/Fortran interface. Both the C and Fortran projects are being compiled with Debug Multithreaded runtime libraries (static).

I guess I am just hoping this error might be familiar to someone and maybe it has a simple solution that I am not aware of. Could it be a bug in the allocate statement? I am probably just stomping over memory somewhere that I have just not yet found, but I have gone through my code several times and not found anything yet. I am getting a little desparate.

I'd appreciate any suggestions,

Chuck

[jimdempseyatthecove]

Chuck,

I do not know if this will work. Try the following

Change

type(string_item), dimension(:), pointer :: sdata=>null()

to

type(string_item), dimension(:), automatic, pointer :: sdata=>null()

I had a similar problem a while back where without automatic the decriptor would be place in static memory as opposed to on the stack. My application uses OpenMP and the multple threads required each to have a seperate descriptor.

Jim Dempsey

[chuckhp]

Thanks for your suggestion, but this one turned out to be user stupidity on my part. I finally tracked the problem down to a misuse of the sprintf function on the C side. I was overwriting a string buffer and corrupting my heap.

I should mention that a found this error by using a very nice tool called gflags.exe. You can download it from here:
http://www.microsoft.com/downloads/details.aspx?familyid=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en
and I found some very nice examples here:
http://technet2.microsoft.com/windowsserver/en/library/4ff86602-1b6e-4a94-80b8-1537084f455c1033.mspx?mfr=true
I followed Example 11, which shows you how to turn on page heap verification, and then I ran my executable through the IVF debugger just like normal. It immediately caught the buffer overrun error that was corrupting my heap. It worked just like promised. I'd recommend it to anyone else having similar problems unless there is a more direct way to do this from within Visual Studio 2005 that I am not aware of.

Chuck