1

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;

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).

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

It might be related to the issue https://issuetracker.delphi-jedi.org/view.php?id=6276

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

mjn
  • 36,362
  • 28
  • 176
  • 378
  • 2
    Can't say that I see anything obviously wrong. Is it always on the same field type, and is the field type in the ftSupported set starting at line 410 (as per the warning in the previous line)? What calculated field type(s) does your app use? – MartynA Jun 10 '20 at 15:45
  • @MartynA debugging the actual AV would be very difficult/time consuming - the AV occurs only once in thousands of function calls. I suspect it is a side effect of some memory allocation / release bug and will ru tests with a different memory manager next week. Many thanks for taking a look! – mjn Jun 10 '20 at 19:03

1 Answers1

0

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

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.

mjn
  • 36,362
  • 28
  • 176
  • 378