Lots of Access Violations in Rio with 9.5.111.1399 (not occuring with v9.4.109.1377)

Data Abstract
1

Hi,

I’ve just migrated from Berlin to Rio and so needed to upgrade to DA 9.5 from 9.4

Now, I have random access violations occurring, all of which trace back into very basic RemObjects DA code - i.e. tbl.Open calls.

These occur with 9.5 in both Berlin and Rio. If I downgrade to 9.4 they don’t occur (in Berlin as I can’t install 9.4 in Rio of course).

This is a very mature app, and I’ve not had any issues before.

Here’s a couple of screen shots of the stoppages with call stacks.

[Album] RemObjects DA v9.5.111.1399 Access Violations

This is causing quite a bit of disruption with my debugging of other software features.

Thanks

Stuart

Edit: I should clarify, the A/V’s don’t appear surface into the app, just seem to break the debugger.

2

Hi,

As I understand, you have AV in FastMM and not in RO/DA code.
try to update FastMM to the latest version from github

3

Hi Evgeny,

Thanks. I thought I had the latest, but I had a rogue entry in the Library path

Sorry - I spoke too soon.

I have the latest version of FastMM4 from the repo & I’m still getting access violations.

I see that they may be coming from FastMM, but the call stack traces back to uROBinMessage & ultimately DADataTable.open.

As I said, this only just started happening with the latest release, didn’t happen before. Has anything changed in the IntReadFromStream ?

Thanks

4

it can be this change .
Looks like it is incompatible with FastMM4

5

Will this be looked at?

Thanks

6

try to replace 1st var with {$IFDEF DELPHI_LINUX}var{$ENDIF} in these methods (uROZlib.pas):

  • ZInternalDecompressEx
  • ZInternalDecompress
  • ZInternalCompressStreamEx
  • ZInternalDecompressStreamEx
  • ZInternalCompressStream
  • ZInternalDecompressStream

will it solve this issue?

7

Hi,

Made the changes as per instructions & I’m getting an EZDecompressionError “stream error” on the first call to DADataTable.Open.

Just to check, for each of the procedures you documented, I changed the method signature as follows.

From

procedure ZInternalDecompressEx(var zstream: TZStreamRec; const inBuffer [..]

to

procedure ZInternalDecompressEx({$IFDEF DELPHI_LINUX}var{$ENDIF} zstream: TZStreamRec; const inBuffer [..]

and rebuilt.

Call stack below.

	01e5a718 +044 uROZLib              2138  +3 Create_EZDecompressionError
	01e5a2c3 +027 uROZLib               717  +7 ZDecompressCheck
	01e5a4b5 +095 uROZLib              1469 +14 ZInternalDecompressStream
	01e5a683 +047 uROZLib              1532  +5 ZDecompressStream
	0203a782 +0d6 uROBinMessage         339 +19 TROBinMessage.IntReadFromStream
	0203b350 +028 uROBinMessage         610  +3 TROBinMessage.ReadFromStream
	01d0fa86 +16a uROTransportChannel   793 +34 TROTransportChannel.Dispatch
	01e96db9 +181 uRODynamicRequest     908 +18 TRODynamicRequest.DoExecute
	01e97bf1 +049 uRODynamicRequest    1209  +4 TRODynamicRequest.Execute
	020ad93f +097 uDARemoteDataAdapter 1513  +5 TDARemoteDataAdapter.InternalFill
	0209461c +128 uDADataAdapter        450  +6 TDABaseDataAdapter.Fill
	020944b1 +0b9 uDADataAdapter        434  +2 TDABaseDataAdapter.Fill
	01ee953e +0a6 uDADataTable         3170  +5 TDADataTable.LoadFromRemoteSource
	01ee8ea0 +0fc uDADataTable         3019 +20 TDADataTable.DoOpen
	020d492c +024 uDAMemDataTable       588  +2 TDAMemDataTable.DoOpen
	01ee942a +00e uDADataTable         3145  +1 TDADataTable.Open

Thanks

8

Hi,

Return this back to var, pls.

How I can reproduce original issue?
I’ve tried to reproduce it with MegaDemo sample but FastMM works correctly with client-side…

I’ve used FastMM4Options.inc (20.7 KB)

9

Morning,

(Sorry, I’m not able to give this 100% attention as I’m nearing a release deadline)

So far, fingers crossed, I’ve only had one further occurrence of the errors. At this point, I’m not 100% what causes it.

I will keep looking and investigating at each occurrence and see if I can narrow it down.

Thanks for the help,

Stuart