I have an odd bug in XE2 when using interfaced objects with properties in generics - would anyone know if this is a known QC?

I have an odd bug in XE2 when using interfaced objects with properties in generics - would anyone know if this is a known QC?

Situation: in a generic class of T with an interface constraint (so T has to support IMyInterface), I'm using an instance of T. T has a property, Filename : string, which uses a GetFilename method.

If I call InstanceOfT.Filename, I get an access violation just off 0x0 when it calls the property access method. (That's as much as my rudimentary assembly can tell me.)  If I use Supports to get the interface my T instance supports, then call Filename using the interface not the object, it works fine.  Usually. In another method, just calling Supports fails with the same access violation inside QueryInterface.

My first thought was that the object itself was invalid - freed, perhaps. But it's not, it is valid, I checked exhaustively tracing through every construction and destruction of every instance (this one is created, and none are destroyed), plus inspecting it looks fine, and has a refcount of 4. Accessing the property in the debugger / evaluator works fine, too, it's only in this code in this generic class. It's only in this generic class, and using the same object instance and accessing the same property of it in other code works fine, before and afterwards. So it's only in this location. It happens with XE2 (untested with most other versions), but does not happen with XE7, I think.  At the moment I'm erring towards thinking it's a compiler bug, which I hope isn't hubris. Do these symptoms sound like a QC anyone knows of, and if so, how can it be worked around?

Comments

  1. David Millington If I recall correctly I did what I usually did: gave up and waited for the fix. I found a ton of issues with generics in XE3 and lower, though by XE6 they were mostly fixed.

    ReplyDelete
  2. David Millington Though your talk of using an instance of T and accessing the interface makes me worried. It's easy to shoot yourself in the foot when mixing them... sure it's not just that?

    ReplyDelete
  3. Asbjørn Heid It's a non-refcounted interfaced object, actually... although, now you mention it, I did see a refcount of 4. I wonder why. I'll look at that this evening.

    I can say its destructor was never called, for sure.

    ReplyDelete

Post a Comment