Has there been an ABI change in the trunk compiler (compared to fpc-3.2.4-rc1) for CORBA interfaces ? Maybe related to "Unicode"-strings ? I have some C++ interfacing code that works fine with fpc-3.2.4-rc1 but crashes with the trunk compiler.

Any hints are appreciated.

Regards,

Adriaan van Os

Op 17-2-2026 om 17:56 schreef Adriaan van Os via fpc-pascal:

Do you really only use the interface, or do you implicitely also use TObject methods or datastructures other than the pure interface?

Afaik Tobject got some methods added for D2009+ compatibility.

I see two new inline procedures, TObject.DisposeOf and TObject.CheckDisposed. I wouldn't expect them to change the size of the vmt, or do they ?

Regards,

Adriaan van Os

Please explain what you mean by "C++ interfacing code" ?

Michael.

The object layout has changed post 3.2 with the addition of an extra field. This breaks any code that makes assumptions about this. I had a problem with the Firebird OO API due to this change (also interfacing to C++), and had to rewrite the Firebird/IBX interface moving away from OO to extended records. -------- Original message --------From: Adriaan van Os via fpc-pascal Date: 17/02/2026 17:05 (GMT+00:00) To: FPC-Pascal users discussions Cc: Adriaan van Os Subject: [fpc-pascal] Corba ABI change ? Has there been an ABI change in the trunk compiler (compared to fpc-3.2.4-rc1) for CORBA interfaces ? Maybe related to "Unicode"-strings ? I have some C++ interfacing code that works fine with fpc-3.2.4-rc1 but crashes with the trunk compiler.Any hints are appreciated.Regards,Adriaan van Os_______________________________________________fpc-pascal maillist  - 

Supplementing my point below, I went back and checked my notes. The TObject layout post 3.2 (in my copy of trunk) is now

       TObject = class
       {$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
       strict private
          _MonitorData : Pointer;
       private
          function SetMonitorData(aData,aCheckOld : Pointer) : Pointer; inline;
          function GetMonitorData: Pointer; inline;        {$ENDIF}
       protected
          function GetDisposed : Boolean; inline;           Property Disposed : Boolean Read GetDisposed;        public

with everything before "public" having been added. The big change is the addition of "_MonitorData". This bumps the offset of all later fields up by sizeof(pointer). If you have code that makes assumptions about the object layout - and this very much applies to code that tries to import an object from C++ then your previous assumptions are invalid.

The advice I got was that for external interfaces, only the "record" layout is immutable between versions. In the end, I had to remove all the Firebird interface code that relied on the assumption that the Pascal object layout was the same as the C++ and replaced it with extended records in order to mimimise the impact on code that used the API.

There's more information about the changes to my code on github https://github.com/MWASoftware/fbintf/tree/main/client/3.0/firebird

Tony Whyman wrote

Supplementing my point below, I went back and checked my notes. The TObject layout post 3.2 (in my copy of trunk) is now

Thanks, this is quite useful.

Regards,

Adriaan van Os

Is SYSTEM_HAS_FEATURE_MONITOR defined by default in the build process ? I assume, the compiler can be built without it ?

Regards,

Adriaan van Os

SYSTEM_HAS_FEATURE_MONITOR seems to be on by default - I never explicitly turned it on, so it probably is the default.

Turning SYSTEM_HAS_FEATURE_MONITOR off may be a good way to show that this is the problem and a short term workaround, but if you are providing source code that you expect to be widely used then you probably need to fix the issue with SYSTEM_HAS_FEATURE_MONITOR turned on.

Pfew.. when you initially wrote your "observations" I didn't realize this issue.
In our product, based on old delphi code, an object is used as "record with methods" to interface with various IP based systems. The methods are used for dissecting packets, endianes conversions, bit fiddling, flag handling etc.
As long as no virtuals were used, an object hadn't any memory overhead.

In our case advanced records are not an option since a large part of the codebase is still used by that old delphi.
That will mean that we need to stick to 3.2

Thanks for warning.
Marc

if you are referring to old TP style objects, your code is unaffected. It only applies to Delphi-style objects.

Michael.

sorry for the noise, misread "class" (and I never expected that someone would use class style objects laid over external data)

Marc

Marc Weustink wrote

In our case advanced records are not an option since a large part of the codebase is still used by that old delphi. That will mean that we need to stick to 3.2

With a few changes, I built 3.3.1 trunk without Monitor support (on MacOS), so without the TObject ABI change. It worked fine.

Regards,

Adriaan van Os

Well, the good news is that you have a proof that the TObject layout change is the cause of your problem. The bad news is that you either have to live with a non-standard build of the compiler/rtl or update your code.