Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

COM interface AUTODEALLOCATEINVOKEARGS crash

andrew_4619
Honored Contributor III
1,005 Views

COM interface AUTODEALLOCATEINVOKEARGS crash

I have a Quickwin App that is crashing using COM interface for Excel. I get memory violations on calls to AUTODEALLOCATEINVOKEARGS.
Some help would be greatly appreciated. A striped down test case (a console application) is attached.
[I will post other details separately as it is not possible to correct and/or /format the original post on this forum]

0 Kudos
7 Replies
andrew_4619
Honored Contributor III
1,005 Views

To summarise the code and behaviour:

[fortran]
CALL COMINITIALIZE(status) ! returns OK status
CALL COMCREATEOBJECT ("Excel.Application.11", excelapp, status) !return OK and a none zero handle excelapp
CALL $Application_SetVisible(excelapp, .FALSE._2) !crashes in the intel created interface routine


SUBROUTINE $Application_SetVisible($OBJECT, $ARG1, $STATUS)
IMPLICIT NONE

INTEGER(INT_PTR_KIND()), INTENT(IN) :: $OBJECT ! Object Pointer
!DEC$ ATTRIBUTES VALUE :: $OBJECT
LOGICAL(2), INTENT(IN) :: $ARG1
!DEC$ ATTRIBUTES REFERENCE :: $ARG1
INTEGER(4), INTENT(OUT), OPTIONAL :: $STATUS ! Method status
!DEC$ ATTRIBUTES REFERENCE :: $STATUS
INTEGER(4) $$STATUS
INTEGER(INT_PTR_KIND()) invokeargs
invokeargs = AUTOALLOCATEINVOKEARGS()
CALL AUTOADDARG(invokeargs, 'Visible', $ARG1)
$$STATUS = AUTOSETPROPERTYBYID($OBJECT, 558, invokeargs)
IF (PRESENT($STATUS)) $STATUS = $$STATUS
CALL AUTODEALLOCATEINVOKEARGS (invokeargs)
END SUBROUTINE $Application_SetVisible
[/fortran]

AUTOALLOCATEINVOKEARGS returns a non-zero pointer, AUTOSETPROPERTYBYID returns an OK status
AUTODEALLOCATEINVOKEARGS crashes the app, as it appears to be accessing memory is shouldn't we get 'invalid heap stamp' error or
if I have weaked around with the code changing unrelated things an invalid (zero) stack pointer, ie something is pointing at a 'random' location.


I have made a console app that uses a small subset of the full code that demonstrates the problem and this is attached. The console app crashes in the same place with an acces violation.


In the Module Excel if I replace:
USE IFAUTO, only : GUID, VARIANT, AUTOALLOCATEINVOKEARGS,.....
with
USE IFAUTO
The problem goes away, 'warn undeclared' is set and both options compile and link OK

0 Kudos
andrew_4619
Honored Contributor III
1,005 Views

For the Record the "USE IFAUTO: Only" was missing AUTODEALLOCATEINVOKEARGS which needs an explicit interface as the handle parameter is passed by VALUE.

0 Kudos
andrew_4619
Honored Contributor III
1,005 Views

... and a further observation for the record the module IFAUTO supplied with Ifort contains USE IFWINTY and  USE IFCOMTY but has zero dependancies for these modules. This seems as lot of baggage given all the declarations are PUBLIC?

0 Kudos
Steven_L_Intel1
Employee
1,005 Views

IFAUTO doesn't use IFWINTY directly. It has USE for IFCOMTY and OLEAUT32. IFCOMTY has selected imports from IFWINTY but OLEAUT32 uses IFWINTY. Generally, we put IFWINTY in the Windows API modules because people tend to need symbols from there. If one could go back to, say, 1995, perhaps a more logical structure could be created, but any changes here now would break programs so we'd rather not mess with it.

0 Kudos
andrew_4619
Honored Contributor III
1,005 Views

I am not sure I fully agree with that, I had a good look at IFAUTO when looking for  my bug.

[fortran]USE IFCOMTY
USE OLEAUT32
use ifwinty[/fortran]

can be replaced with

[fortran]USE OLEAUT32, only : VARIANTINIT, VARIANTCLEAR[/fortran]

as those are the only dependancies in IFAUTO. I 

0 Kudos
Steven_L_Intel1
Employee
1,005 Views

I went back to version 12.0 and don't see ifwinty mentioned. Here's what it looks like:

[fortran]
MODULE IFAUTO
!dec$objcomment lib: "ifauto.lib"
      USE IFCOMTY
      USE OLEAUT32
      IMPLICIT NONE
[/fortran]

Yes, making that replacement would allow IFAUTO to compile, but it might break applications that depend on IFAUTO to bring in IFWINTY and/or OLEAUT32. This is the sort of thing we don't change without a REALLY good reason as it will break customer builds.

0 Kudos
andrew_4619
Honored Contributor III
1,005 Views

Yes I correct myself slightly  it is OLEAUT32 that includes IFWINTY despite OLEAUT32 have no dependancies on on IFWINTY. 

0 Kudos
Reply