versiones - delphi wikipedia

¿Está descompuesto COM en XE2 y cómo podría solucionarlo?

Question

Actualización: XE2 Actualización 2 corrige el error que se describe a continuación.

El programa a continuación, recortado del programa real, falla con una excepción en XE2. Esta es una regresión de 2010. No tengo XE para probar pero espero que el programa funcione bien en XE (gracias a Primož por confirmar que el código funciona bien en XE).

program COMbug;

{$APPTYPE CONSOLE}

uses
  SysUtils, Variants, Windows, Excel2000;

var
  Excel: TExcelApplication;
  Book: ExcelWorkbook;
  Sheet: ExcelWorksheet;
  UsedRange: ExcelRange;
  Row, Col: Integer;
  v: Variant;

begin
  Excel := TExcelApplication.Create(nil);
  try
    Excel.Visible[LOCALE_USER_DEFAULT] := True;
    Book := Excel.Workbooks.Add(EmptyParam, LOCALE_USER_DEFAULT) as ExcelWorkbook;
    Sheet := Book.Worksheets.Add(EmptyParam, EmptyParam, 1, EmptyParam, LOCALE_USER_DEFAULT) as ExcelWorksheet;

    Sheet.Cells.Item[1,1].Value := 1.0;
    Sheet.Cells.Item[2,2].Value := 1.0;
    UsedRange := Sheet.UsedRange[LOCALE_USER_DEFAULT] as ExcelRange;
    for Row := 1 to UsedRange.Rows.Count do begin
      for Col := 1 to UsedRange.Columns.Count do begin
        v := UsedRange.Item[Row, Col].Value;
      end;
    end;
  finally
    Excel.Free;
  end;
end.

En XE2 32 bit el error es:

Proyecto COMbug.exe provocó la clase de excepción $ C000001D con mensaje ''excepción de sistema (código 0xc000001d) en 0x00dd6f3e''.

El error ocurre en la segunda ejecución de UsedRange.Columns .

En XE2 64 bit el error es:

El proyecto COMbug.exe generó la clase de excepción $ C0000005 con el mensaje ''c0000005 ACCESS_VIOLATION''

De nuevo, creo que el error ocurre en la segunda ejecución de UsedRange.Columns , pero el depurador de 64 bits UsedRange.Columns por el código de una manera un poco extraña, así que no estoy 100% seguro de eso.

He enviado un informe de control de calidad para el problema.

Me parece mucho como si algo en la pila de COM / automatización / interfaz de Delphi estuviera completamente roto. Este es un completo stop-show para mi adopción de XE2.

¿Alguien tiene alguna experiencia con este problema? ¿Alguien tiene consejos y consejos sobre cómo puedo tratar de solucionar el problema? La depuración de lo que realmente sucede aquí está fuera de mi área de experiencia.

Answer 1

Solución

rowCnt := UsedRange.Rows.Count;
colCnt := UsedRange.Columns.Count;
for Row := 1 to rowCnt do begin
  for Col := 1 to colCnt do begin
    v := UsedRange.Item[Row, Col].Value;
  end;
end;

Esto también funciona (y puede ayudarlo a encontrar una solución alternativa en casos de uso más complicados):

function ColCount(const range: ExcelRange): integer;
begin
  Result := range.Columns.Count;
end;

for Row := 1 to UsedRange.Rows.Count do begin
  for Col := 1 to ColCount(UsedRange) do begin
    v := UsedRange.Item[Row, Col].Value;
  end;
end;

Análisis

Se bloquea en System.Win.ComObj en DispCallByID al ejecutar _Release en

varDispatch, varUnknown:
  begin
    if PPointer(Result)^ <> nil then
      IDispatch(Result)._Release;
    PPointer(Result)^ := Res.VDispatch;
  end;

Aunque la versión PUREPASCAL de este mismo procedimiento en Delphi XE (XE usa una versión de ensamblador) es diferente ...

varDispatch, varUnknown:
  begin
    if PPointer(Result)^ <> nil then
      IDispatch(Result.VDispatch)._Release;
    PPointer(Result)^ := Res.VDispatch;
  end;

... el código de ensamblador en ambos casos es el mismo (EDITAR: no es cierto, vea mis notas al final):

@ResDispatch:
@ResUnknown:
        MOV     EAX,[EBX]
        TEST    EAX,EAX
        JE      @@2
        PUSH    EAX
        MOV     EAX,[EAX]
        CALL    [EAX].Pointer[8]
@@2:    MOV     EAX,[ESP+8]
        MOV     [EBX],EAX
        JMP     @ResDone

Curiosamente, esto se bloquea ...

for Row := 1 to UsedRange.Rows.Count do begin
  for Col := 1 to UsedRange.Columns.Count do begin
  end;
end;

... y esto no.

row := UsedRange.Rows.Count;
col := UsedRange.Columns.Count;
col := UsedRange.Columns.Count;

La razón de esto es el uso de variables locales ocultas. En el primer ejemplo, el código se compila para ...

00564511 6874465600       push $00564674
00564516 6884465600       push $00564684
0056451B A12CF35600       mov eax,[$0056f32c]
00564520 50               push eax
00564521 8D8508FFFFFF     lea eax,[ebp-$000000f8]
00564527 50               push eax
00564528 E8933EEAFF       call DispCallByIDProc

... y eso se llama dos veces.

En el segundo ejemplo, se usan dos ubicaciones temporales diferentes en la pila (compensaciones de ebp - ????):

00564466 6874465600       push $00564674
0056446B 6884465600       push $00564684
00564470 A12CF35600       mov eax,[$0056f32c]
00564475 50               push eax
00564476 8D8514FFFFFF     lea eax,[ebp-$000000ec]
0056447C 50               push eax
0056447D E83E3FEAFF       call DispCallByIDProc
...
0056449B 6874465600       push $00564674
005644A0 6884465600       push $00564684
005644A5 A12CF35600       mov eax,[$0056f32c]
005644AA 50               push eax
005644AB 8D8510FFFFFF     lea eax,[ebp-$000000f0]
005644B1 50               push eax
005644B2 E8093FEAFF       call DispCallByIDProc

El error se produce cuando se borra una interfaz interna almacenada en esta ubicación temporal, lo que ocurre solo cuando se ejecuta el caso "para" por segunda vez porque ya hay algo almacenado en esta interfaz: se colocó allí cuando se llamó "para" por primera vez. En el segundo ejemplo, se utilizan dos ubicaciones, por lo que esta interfaz interna siempre se inicializa en 0 y no se llama en absoluto a la versión.

El verdadero error es que esta interfaz interna contiene basura y cuando se lanza Release, ocurre sh! T.

Después de investigar un poco más, me di cuenta de que el código ensamblador que libera la interfaz anterior no es el mismo: a la versión XE2 le falta una instrucción "mov eax, [eax]". IOW,

IDispatch(Result)._Release;

es un error y realmente debería ser

IDispatch(Result.VDispatch)._Release;

Nasty error RTL.

Answer 2

La mayor parte de esto está por encima de mi cabeza, pero me pregunto si se requerirá una llamada a CoInitialize. La búsqueda en la web de CoInitialize devolvió esta página:

http://chrisbensen.blogspot.com/2007/06/delphi-tips-and-tricks.html

Casi parece que esa página describe el problema del OP y el análisis de gabr en lo que se refiere a una llamada a .Release. Mover la funcionalidad del código en su propio procedimiento podría ayudar. No tengo XE o XE2 para probar.

Editar: Ratas: la intención es agregar esto como un comentario al anterior.