Exception in TRRIEnumerationType.Create when called by TRORTTIClientCache.RebuildCache

Remoting SDK
1

I have just migrated our copy of RemObjects SDK from 9.4 to 10.0 and while I had to adjust a few uses along the way, compilation went quite smoothly.
However, I now have an issue at runtime with an exception being raised at the top of this call stack:

System.Rtti.TRttiEnumerationType.Create(???,nil,$C42FA10)
System.Rtti.TRttiPackage.ReadObject(TRttiEnumerationType,nil,$1D8A703)
System.Rtti.TRttiPackage.ReadObjectPointer(???,???,$1D8A6E0)
System.Rtti.GetType($1D8A6E0)
System.Rtti.TRealPackage.GetTypes
System.Rtti.TRttiPool.GetTypes
System.Rtti.TRttiContext.GetTypes
uRORTTISupport.TRORttiClientCache.RebuildCache
uRORTTISupport.TRORttiClientCache.GetROComplexClass('TSCEnvironment',$6F5FD60)
uRORTTISupport.RORTTI_FindROClass('TSCEnvironment',$6F5FD60)
uROTypes.FindROClass('TSCEnvironment',$6F5FD60)

The exception message is this:

Access violation at address 004DC390 in module "MyApp.exe''. Read of address 00000000

This application is built with Delphi 10 Seattle, so I went into at line 270 in RemObjects.inc and surrounded {$DEFINE RO_RTTI_Support} with an IFDEF DELPHI_BERLIN_UP and I’m back in business.

But I’m reporting the issue here because I worry that this will show up again when we finally migrate our development chain to Delphi 10.4

Have you had similar reports with this?
It seems this is related to enumerations but I’m not sure what’s going on here…

2

Ok, it does not come from your code, I have something in my own code that makes the advanced RTTI system completely freak out.
But that means I must always disable RTTI support in RemObjects SDK to avoid a crash. What are the drawbacks here?

3

Hi,

We use the RO_RTTI_Support definition only for CodeFirst service support so if you don’t use CodeFirst services, you can completely disable RO RTTI support.
that definition should be commented in RemObjects.inc & DataAbstract.inc

4

I don’t use such services, so I’ll be alright, thanks for confirming it.