Problem running delphi app on AMD64 chips
Hi, we have an app written in Delphi 5 that will not run (wont even start up) on some AMD64 chip machines running XP.
We have never had a problem with any other machine (Intel / AMD, or Operating system).
Some AMD machines that have displayed this problem have been fixed by applying a bios update, but other machines still have problems even after the bios update has been run.
I searched on Google and there are some issues with Windows XP Service Pack 2 and some new security feature re stack allocation etc, but found nothing pointing to any particular calls etc...I suspect this may be the cause, but I am not sure what calls need to be checked / changed to suit XP Sp2.
I am probably asking this question prematurely, as we are currently sourcing an AMD64 machine to try and work out why, but I was wondering if anybody else had experienced this?
Thanks
We have never had a problem with any other machine (Intel / AMD, or Operating system).
Some AMD machines that have displayed this problem have been fixed by applying a bios update, but other machines still have problems even after the bios update has been run.
I searched on Google and there are some issues with Windows XP Service Pack 2 and some new security feature re stack allocation etc, but found nothing pointing to any particular calls etc...I suspect this may be the cause, but I am not sure what calls need to be checked / changed to suit XP Sp2.
I am probably asking this question prematurely, as we are currently sourcing an AMD64 machine to try and work out why, but I was wondering if anybody else had experienced this?
Thanks
does this happen only to Delphi applications?
ASKER
It is only one particular Delphi app that we have this problem with. It is written in-house, and has been sold commercially for a couple of years with no problem. It is only the AMD64 chips (and only some of them) that seem to cause an issue.
My AMD64 is configured so that every application crashes which isn't properly written (boot.ini "/NoExecute=OptOut"). I've already noticed that BCB5 isn't properly written and needs to be listed in the OptOut settings. Delphi5 runs just fine, though. And also small D5 compiled exes run just fine on my PC.
ASKER
Thanks, we now have an AMD64 machine. I've tried turning that switch to AlwaysOff, but the app still locks.
It is always after it has done a http call to one of our servers to retreive data, I am guessing it is about to write this data to the hdd, then the whole machine just freezes....no error, no keyboard, no mouse.. dead!
I could understand if this happened on all machines, but its only a few AMD 64's that have this same issue.
I guess (reluctantly) the next step is to install the dev environment on the test machine and debug it from there.
It is always after it has done a http call to one of our servers to retreive data, I am guessing it is about to write this data to the hdd, then the whole machine just freezes....no error, no keyboard, no mouse.. dead!
I could understand if this happened on all machines, but its only a few AMD 64's that have this same issue.
I guess (reluctantly) the next step is to install the dev environment on the test machine and debug it from there.
ASKER
Ok, we have narrowed it down to this line of code.
Move(DataRec.Data[Position
If we change this to say sizeOf(Double) then it all works fine - we dont want to do this if possible as we would need to modify all of our existing data to store as double values rather than integers.
Running it on an Intel CPU works fine with SizeOf(Integer).
Something has changed in the way AMD64 chips handle integer data types.
We have checked the sizeof(integer) and it returns 4 bytes - on both the intel and AMD - as expected.
If we leave it as SizeOf(Integer) the AMD machine locks completely.
The declarations are below.
iTemp : integer;
Position : integer;
TPackedByteArray = packed array of byte;
TDataRecord = packed record
NextRecord : integer;
PreviousRecord : integer;
dDateTime: TDateTime;
Data : TPackedByteArray;
end;
Any ideas?
Thanks
Move(DataRec.Data[Position
If we change this to say sizeOf(Double) then it all works fine - we dont want to do this if possible as we would need to modify all of our existing data to store as double values rather than integers.
Running it on an Intel CPU works fine with SizeOf(Integer).
Something has changed in the way AMD64 chips handle integer data types.
We have checked the sizeof(integer) and it returns 4 bytes - on both the intel and AMD - as expected.
If we leave it as SizeOf(Integer) the AMD machine locks completely.
The declarations are below.
iTemp : integer;
Position : integer;
TPackedByteArray = packed array of byte;
TDataRecord = packed record
NextRecord : integer;
PreviousRecord : integer;
dDateTime: TDateTime;
Data : TPackedByteArray;
end;
Any ideas?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
okay problem fixed.
turns out to be a different line, but still moving memory with itemp and sizeof(integer).
we were initially populating itemp with trunc(some double value) to get just the whole integer value.
It turns out that trunc returns an int64, which is 8 bytes on a 64 bit machine, then we were trying to move this into a 4 byte integer.
We got rid of the trunc by using ceil instead.
Thanks for your help.
turns out to be a different line, but still moving memory with itemp and sizeof(integer).
we were initially populating itemp with trunc(some double value) to get just the whole integer value.
It turns out that trunc returns an int64, which is 8 bytes on a 64 bit machine, then we were trying to move this into a 4 byte integer.
We got rid of the trunc by using ceil instead.
Thanks for your help.