TJvMemoryData.InternalSetFieldData中的偶发访问冲突 [英] Sporadic Access Violation in TJvMemoryData.InternalSetFieldData

问题描述

我正在尝试解决此代码中发生的Delphi XE7应用程序中的访问冲突，该代码是Jedi VCL JvMemoryDataset组件的一部分（当前来源在Github）：

I am trying to resolve an access violation in a Delphi XE7 application which is occurs in this code, which is part of the Jedi VCL JvMemoryDataset component (current source at Github):

begin
  Data^ := Ord(Buffer <> nil);
  Inc(Data);
  if Buffer <> nil then
    Move(Buffer^, Data^, CalcFieldLen(Field.DataType, Field.Size)) <---------- AV here
  else
    FillChar(Data^, CalcFieldLen(Field.DataType, Field.Size), 0);
end;

代码偶然地导致地址04020111发生读取访问冲突。此代码中的一个明显问题？ （CalcFieldLen可能返回0，不确定此处是否相关）。

The code sporadically causes a read access violation at address 04020111. Is there an obvious problem in this code? (CalcFieldLen might return 0, not sure if this is relevant here).

我检查了JVCL的当前开发版本，Move调用与我的（较旧的）本地版本相同。

I have checked the current development version of JVCL and the Move call is the same as in my (older) local version.

这可能与问题 https：// issuetracker有关。 delphi-jedi.org/view.php?id=6276

相关（有调试建议）： 从D2006到XE5，在XP兼容模式下不会发生

Related (with debugging suggestions): Sporadic Access Violation after porting from D2006 to XE5, doesn't happen in XP compatibility mode

推荐答案

在切换 FetchOptions.Unidirectional 属性设置为True 。 （属性默认值为False）。

The access violation disappeared after switching the FetchOptions.Unidirectional property of the FireDAC query to True. (The property default value is False)

我猜这种访问冲突是由于低内存情况下的内存损坏引起的。 FireDAC查询已关闭并重新打开（通过大型数据集进行分页），因此在加载的数据量很高时发生。

I guess this access violation was caused by memory corruption in low-memory situations. The FireDAC query was closed and re-opened (paging through a large dataset) so it happened when the amount of loaded data was high.

这篇关于TJvMemoryData.InternalSetFieldData中的偶发访问冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！