Access violation at libifcoremdd!for_set_reentrancy+0x17f in formatted read?

[a_cockburn]

Hi

I am having an access violation in the following fortran code:

subroutine Unscram_Str0(string,new,ier)
implicit none

character(*), intent (in) :: string
character(*), intent (out) :: new
integer*4, intent (out) :: ier

! Local variables

integer*4 :: ad1, ad2, data1, data2, sad1, sad2, sdata1, sdata2

new = ' '

read (string(1:2),'(i2)',err=100) ad1

The read statement calls for_read_int_fmt, and there is an access violation in for_set_reentrancy, in libifcoremdd.dll. An access violation also occurs in release builds.

This problem is only reproducable on client machines. I am doing remote debugging using cdb. The following is the relevant part of the cdb log:

0:000> g
Breakpoint 15 hit
eax=00000014 ebx=0013ea60 ecx=00000001 edx=0000002f esi=0012f344 edi=0012f534
eip=04aa626b esp=0012eb5c ebp=0012ecac iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
workspace!UNSCRAM_STR0+0x2f:
04aa626b 8b4514 mov eax,dword ptr [ebp+14h] ss:0023:0012ecc0=00000014
0:000> g
(7ec.830): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=fffffffb ecx=0012f6bc edx=00000000 esi=0012eb30 edi=7c59c16b
eip=04d3269b esp=0012ea40 ebp=0012ea54 iopl=0 nv up ei ng nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010296
*** ERROR: Symbol file could not be found. Defaulted to export symbols for E:StruCadV12StruCadinlibifcoremdd.dll -
libifcoremdd!for_set_reentrancy+0x17f:
04d3269b 8907 mov dword ptr [edi],eax ds:0023:7c59c16b=0d681072
0:000> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0012ea54 04d32836 libifcoremdd!for_set_reentrancy+0x17f
0012ea60 04d36309 libifcoremdd!for_set_reentrancy+0x31a
0012eaa4 04d9103b libifcoremdd!fq_settextposition+0x7e9
0012eb40 04aa639a libifcoremdd!for_read_int_fmt+0x23
0012ecac 04aa1ba7 workspace!UNSCRAM_STR0( STRING = , long .tmp..T426_.I.SI32 = 14, NEW = , long .tmp..T431_.I.SI32 = 20, long * IER = 0x0012f420)+0x15e

The 'string' being passed in to Unscram_Str0 is part of a common block. I can confirm, by debugging the assembler of Unscram_Str0, that the correct address of this string is
being passed d own to for_read_int_fmt, and the two characters being'read' are '54'. The read statement is indeed the line referenced in the log. The file and product versions of libifcoremdd.dll are 9.1.101.101 and 9.1.101.0 respectively.

My questions are:
1 Has anyone seen anything like this before? If so, what was the cause?
2 If anyone in the Intel Fortran team knows the source code of for_set_reentrancy, and knows what would cause an access violation at for_set_reentrancy+0x17f, could they reply?
3 Is there a symbol file for this version of libifcoremdd.dll? With it I could verify that the argument to for_read_int are as expected.

Any help or advice would be greatly appreciated.

Andre

[Steven_L_Intel1]

The name for_set_reentrancy is a red herring - it has nothing to do with your problem, based on the stack trace. Can you reproduce the problem when linked statically? Which compiler version (exact - 9.1.???) are you using?

[a_cockburn]

Hi Steve,

Thanks for your reply.

I have managed to alter the contributary projects to link against the static Fortran and C runtime libraries. This does solve the problem on the customer machine that had the problem.

It would, however, be very useful to us if we could solve the problem using the DLL runtime libraries.

Our support people tell us that the problem occurs on machines with Windows 2000 and XP SP 1, but the problem disappears when customers install SP 2. We do, however, have a number of clients with Windows 2000. The client machine I am remote debugging onto is Windows 2000.

Another strange thing I've noticed is that if I view the contents of the common block containing 'string' at a breakpoint, no violation occurs.

I am usung Intel Fortran Compiler for 32-bit applications, Version 9.1 Build 20060706Z Package ID: W_FC_C_9.1.028. The problem also occurs when it is built with 9.1.025.

If there is any memory I can dump or any other information I can get pass on that will help, please let me know.

Andre

[Steven_L_Intel1]

I would recommend building with 9.1.034 and see what happens. Unfortunately, there is nothing I can think of that you can "dump" - my guess is that there's a Microsoft Visual C++ RTL bug that was fixed by XP SP2. On XP, the MSVC DLLs are considered part of the system and therefore can't be superceded by the user. On Windows 2000, though, you can try putting the dependent MSVC DLL in the same folder as the Fortran DLLs and see what happens.

[a_cockburn]

Hi Steve,

Thanks for your reply.

I think I should have said that the project we are building is a dll that is called from a .NET executable. Even if we put the new msvcrt.dll in the directory of the executable and dll, the system32msvcrt.dll is loaded by the framework beforeour dll is loaded.

The problem persiested when using the new compiler. I have managed to get a trace of what was going wrong with the original customer problem. The access voilation occured a call to libifcoremdd!for_write_seq_nml+0xc524 -> msvcrt!signal is returned to libifcoremdd!for_set_reentrancy. The problem persiested when using the new compiler. The following is from the trace:

libifcoremdd!for_set_reentrancy+0x175:
04d22691 ff15b051da04 call dword ptr [libifcoremdd!for_write_seq_nml+0xc524 (04da51b0)] ds:0023:04da51b0={msvcrt!signal (7800ccdf)}
msvcrt!signal:
7800ccdf 55 push ebp

and on return from signal

msvcrt!signal+0x182:
7800ce6d c9 leave
msvcrt!signal+0x183:
7800ce6e c3 ret
libifcoremdd!for_set_reentrancy+0x17b:
04d22697 6a01 push 1
libifcoremdd!for_set_reentrancy+0x17d:
04d22699 6a16 push 16h
libifcoremdd!for_set_reentrancy+0x17f:
04d2269b 8907 mov dword ptr [edi],eax ds:0023:7c59c16b=0d681072

The last instruction gives the access voilation.

Does this give you any clue as to what is causing the problem.

I could email you directly a zipfile containing this trace, if this is useful.

Thanks in advance.

Andre

[Steven_L_Intel1]

No. a trace does not do me any good. I'd suggest filing a support request with Intel Premier Support and attach what you can. Without a test case, though, don't get your hopes up.