COM 在 XE2 中是否损坏，我该如何解决? [英] Is COM broken in XE2, and how might I work around it?
问题描述
更新: XE2 Update 2 修复了下述错误.
下面的程序，从实际程序中删减，在 XE2 中失败并出现异常.这是 2010 年的回归.我没有 XE 可以测试，但我希望程序在 XE 上运行良好(感谢 Primož 确认代码在 XE 上运行良好).
程序 COMbug;{$APPTYPE 控制台}用途SysUtils、变体、Windows、Excel2000；变量Excel:TExcelApplication；书籍:ExcelWorkbook；工作表:Excel工作表；使用范围:ExcelRange；行，列:整数；v:变体；开始Excel := TExcelApplication.Create(nil);尝试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;对于 Row := 1 到 UsedRange.Rows.Count 开始对于 Col := 1 到 UsedRange.Columns.Count 开始v := UsedRange.Item[Row, Col].Value;结尾;结尾;最后Excel.免费；结尾;结尾.在 XE2 32 位中，错误是:
<块引用>项目 COMbug.exe 引发异常类 $C000001D，并带有消息系统异常(代码 0xc000001d)在 0x00dd6f3e".
第二次执行UsedRange.Columns时出现错误.
在 XE2 64 位中，错误是:
<块引用>项目 COMbug.exe 引发异常类 $C0000005，消息为c0000005 ACCESS_VIOLATION"
再次，我认为错误发生在第二次执行 UsedRange.Columns 时，但是 64 位调试器以一种有点奇怪的方式逐步执行代码，所以我不能 100% 确定那个.
我已针对该问题提交了QC 报告.p>
在我看来，Delphi COM/automation/interface 堆栈中的某些东西被彻底破坏了.这对我采用 XE2 来说是一个完整的展示.
有人遇到过这个问题吗?有人对我如何尝试解决该问题有任何提示和建议吗?调试这里真正发生的事情超出了我的专业领域.
解决方法
rowCnt := UsedRange.Rows.Count;colCnt := UsedRange.Columns.Count;对于 Row := 1 到 rowCnt 开始对于 Col := 1 到 colCnt 开始v := UsedRange.Item[Row, Col].Value;结尾;结尾;这也有效(并且可以帮助您在更复杂的用例中找到解决方法):
function ColCount(const range: ExcelRange): integer;开始结果 := range.Columns.Count;结尾;对于 Row := 1 到 UsedRange.Rows.Count 开始for Col := 1 to ColCount(UsedRange) 开始v := UsedRange.Item[Row, Col].Value;结尾;结尾;分析
执行_Release in时在DispCallByID中System.Win.ComObj崩溃
varDispatch, varUnknown:开始if PPointer(Result)^ <>则为零IDispatch(Result)._Release;PPointer(Result)^ := Res.VDispatch;结尾;虽然在 Delphi XE(XE 使用汇编版本)中这个相同程序的 PUREPASCAL 版本是不同的......
varDispatch, varUnknown:开始if PPointer(Result)^ <>则为零IDispatch(Result.VDispatch)._Release;PPointer(Result)^ := Res.VDispatch;结尾;...这两种情况下的汇编代码是相同的(不正确，见我的笔记在最后):
@ResDispatch:@ResUnknown:MOV EAX,[EBX]测试EAX，EAX杰@@2推EAXMOV EAX,[EAX]调用 [EAX].Pointer[8]@@2: 移动 EAX,[ESP+8]MOV [EBX],EAXJMP @ResDone有趣的是，这崩溃了......
for Row := 1 to UsedRange.Rows.Count 开始对于 Col := 1 到 UsedRange.Columns.Count 开始结尾;结尾;...这不是.
row := UsedRange.Rows.Count;col := UsedRange.Columns.Count;col := UsedRange.Columns.Count;这样做的原因是使用了隐藏的局部变量.在第一个示例中，代码编译为 ...
00564511 6874465600 推送 $0056467400564516 6884465600 推 $005646840056451B A12CF35600 移动 eax,[$0056f32c]00564520 50推eax00564521 8D8508FFFFFF lea eax,[ebp-$000000f8]00564527 50推eax00564528 E8933EEAFF 调用 DispCallByIDProc...这被调用了两次.
在第二个示例中，使用了堆栈上的两个不同的临时位置(ebp - ???? 偏移量):
00564466 6874465600 推送 $005646740056446B 6884465600 推 $0056468400564470 A12CF35600 移动 eax，[$0056f32c]00564475 50推eax00564476 8D8514FFFFFF lea eax,[ebp-$000000ec]0056447C 50 推0056447D E83E3FEAFF 调用 DispCallByIDProc...0056449B 6874465600 推 $00564674005644A0 6884465600 推 $00564684005644A5 A12CF35600 移动 eax,[$0056f32c]005644AA 50 推005644AB 8D8510FFFFFF lea eax，[ebp-$000000f0]005644B1 50 推005644B2 E8093FEAFF 调用 DispCallByIDProc当清除存储在此临时位置的内部接口时会发生该错误，仅当第二次执行for"案例时才会发生，因为该接口中已经存储了一些东西 - 当for"时它被放在那里第一次被叫到.在第二个示例中，使用了两个位置，因此该内部接口始终初始化为 0，并且根本不调用 Release.
真正的错误是这个内部接口包含垃圾，当调用 Release 时，sh!t 发生.
经过一番挖掘，我注意到释放旧接口的汇编代码不一样 - XE2 版本缺少一条mov eax，[eax]"指令.爱荷华，
IDispatch(Result)._Release;是一个错误，它真的应该是
IDispatch(Result.VDispatch)._Release;讨厌的 RTL 错误.
Update: XE2 Update 2 fixes the bug described below.
The program below, cutdown from the real program, fails with an exception in XE2. This is a regression from 2010. I don't have XE to test on but I'd expect that the program works fine on XE (thanks to Primož for confirming that the code runs fine on 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.
In XE2 32 bit the error is:
Project COMbug.exe raised exception class $C000001D with message 'system exception (code 0xc000001d) at 0x00dd6f3e'.
The error occurs on the second execution of UsedRange.Columns.
In XE2 64 bit the error is:
Project COMbug.exe raised exception class $C0000005 with message 'c0000005 ACCESS_VIOLATION'
Again, I think that the error occurs on the second execution of UsedRange.Columns, but the 64 bit debugger steps through the code in a slightly weird way so I'm not 100% sure of that.
I have submitted a QC report for the issue.
I looks very much to me as though something in the Delphi COM/automation/interface stack is comprehensively broken. This is a complete show-stopper for my XE2 adoption.
Does anyone have any experience of this problem? Does anyone have any tips and advice as to how I might attempt to work around the problem? Debugging what's really going on here is outside my area of expertise.
Workaround
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;
This also works (and may help you find a workaround in more complicated use cases):
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;
Analysis
It crashes in System.Win.ComObj in DispCallByID when executing _Release in
varDispatch, varUnknown:
begin
if PPointer(Result)^ <> nil then
IDispatch(Result)._Release;
PPointer(Result)^ := Res.VDispatch;
end;
Although the PUREPASCAL version of this same procedure in Delphi XE (XE uses an assembler version) is different ...
varDispatch, varUnknown:
begin
if PPointer(Result)^ <> nil then
IDispatch(Result.VDispatch)._Release;
PPointer(Result)^ := Res.VDispatch;
end;
... the assembler code in both cases is the same (EDIT: not true, see my notes at the end):
@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
Interestingly enough, this crashes ...
for Row := 1 to UsedRange.Rows.Count do begin
for Col := 1 to UsedRange.Columns.Count do begin
end;
end;
... and this doesn't.
row := UsedRange.Rows.Count;
col := UsedRange.Columns.Count;
col := UsedRange.Columns.Count;
The reason for this is the use of hidden local variables. In the first example, the code compiles to ...
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
... and that is called twice.
In the second example, two different temporary locations on the stack are used (ebp - ???? offsets):
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
The bug occurs when an internal interface stored in this temporary location is being cleared, which happens only when the "for" case is executed for the second time because there's something already stored in this interface - it was put there when "for" was called for the first time. In the second example, two locations are used so this internal interface is always initialized to 0 and Release is not called at all.
The true bug is that this internal interface contains garbage and when Release is called, sh!t happens.
After some more digging, I noticed that the assembler code that frees the old interface is not the same - XE2 version is missing one "mov eax, [eax]" instruction. IOW,
IDispatch(Result)._Release;
is a mistake and it really should be
IDispatch(Result.VDispatch)._Release;
Nasty RTL bug.
这篇关于COM 在 XE2 中是否损坏，我该如何解决?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
