Hello,

I have been a user of your excellent DOA for years and I am now trying to convert a dll project to 64bit. But I am getting access violations when run from IIS and I believe I have found some problems in your code:

For example:

function TObjectAttribute.ValuePtr: Pointer;
begin
Result := Pointer(LongInt(Owner.Instance) + ValueOffset);
if IsCollection or NotFinal or (TypeName = 'SYS.XMLTYPE') then Result := PPointer(Result)^;
end;

Owner.Instance (64bit pointer) is converted to a LongInt (32bit integer) and then ValueOffset (32bit integer) is added to it and then it is converted back to a 64bit pointer.

The will work fine as long as the address of Owner.Instance is <2^32, as soon as the address of Owner.Instance is >2^32 then it is truncated and the resultant pointer is invalid.

The same problem can be seen in other places in your code, for example in TOracleProvider.GetRecords

D := Pointer(Integer(S) + HeaderSize);
S := Pointer(Integer(S) + HeaderSize + MetaDataSize);

There maybe other places as well, one solution is to use NativeInt instead of Integer/LongInt for pointer arithmetic.

Here is a similar bug posted on StackOverflow:

http://stackoverflow.com/questions/15930608/copymemory-causes-access-violation-on-win8

Also I have had a similar discussion with the author of another third-party library here:

http://synopse.info/forum/viewtopic.php?id=1913

He was good enough to fix the issues straight away.

Also I am getting consistent access violations at the following line when testing my 64bit dll:

TOracleQuery.GetRowId:

riObject := (p[1] shl 24) + (p[2] shl 16) + (p[3] shl 8) + p[4];

I am unsure to the cause of this but:

p is constructed from:

if rowidhp <> nil then p := Pub1Array(Tub4Array(rowidhp^)[2]) else p := nil;

But Tub4Array is an array of LongInt, so you are taking a 32 bit longint and casting it a 64 bit pointer. I know nothing of the OCI.dll interface but wouldn't the 64bit version of the dll return an array of 64bit pointers and not 32bit pointers?

So shouldn't Tub4Array be declared as:

Tub4Array = array[0..500000000] of NativeInt;

instead ?

I really hope you can fix these issues, DOA really is a great library. A useful way of testing for 64bit pointer arithmetic errors is to include the full version of FastMM in you test unit and define FULLDEBUGMODE, this will cause FastMM to allocate memory top down, so addresses over 4GB are allocated first. This soon shows up 64bit pointer errors.


Thanks,

Adrian

Thanks for reporting this, we'll check it out.