Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
System.OverflowException when calling ByteArray.AsDelphiArray

I am transferring byte arrays from .Net to Delphi. This operation is repeated thousands of times and the length of the byte array is beteeen 5k and 500k. The operations runs without issues for a couple of minutes but then crashes on the .Net side with the following error:

  Message=Arithmetic operation resulted in an overflow.
  at Atozed.CrossTalk.Right.CTStreamReader.Read() in Atozed.CrossTalk.Right\CTStreamReader.cs:line 67

  This exception was originally thrown at this call stack:
    Atozed.CrossTalk.Right.CTStreamReader.Read() in CTStreamReader.cs

On the Delphi side I am using ByteArray.AsDelphiArray to get the bytes. The exception is happening when this method is called.

If I take the same byte array which causes this and transfer it in isolation (e.g. without making any other transfers beforehand) then everything works fine. So the error is caused by repeating the operation many times with different arrays.
I have already tried to use CopyToDelphiArray instead but it yields the same error.
I have also added a logic which catches this error and reverts to use a for loop to get the bytes from the ByteArray by index. This works but unacceptable slow. Note that once the exception was thrown AsDelphiArray only works for a couple of calls and then the same exception is thrown.
Can you make a simple ready to run project which demonstrates this so we can run it and test?

It looks like something very simple to fix once we can locate it.

I would need to capture all the calls made in our app and simulate the same which would be a massive job.

Doesn't OverflowException at CTStreamReader.cs:line gives you some clue?
Im sorry this thread got buried over the holidays.

Yes it does give a big clue. But it would be very helpful to provide a simple use case. You dont need to pare down your existing application. You should be able to create a new project which demonstrates the situation and produces the crash. This will allow us to focus on fixing the issue and not trying to guess at what leads up to it.

As you can see what is going on in your app, this normally is pretty easy to reproduce in a new console demo. Can you see if you can repro it in a simple console app using CT? I can schedule the team to look at it with high priority then.


unfortunately with a simple command line app the problem is not happening. I would need to capture all the calls from our main app and simulate these calls in the command line app to recreate the issue. This would be a considerable amount work and it has not been approved by management. Maybe it is possible to see and fix the problem just by looking at the source?

I can take a look, but without a reproducible case I cannot promise anything.
Thanks. Even if I would create an command line app trying to "simulate" the error fixing that error does not necesseraly mean that it will be also fixed in the real application.

Fingers crossed you can come up with a good fix :-)
Hi Geza, how's it going? :-)

I'll talk to you in private and see what we can find out

today by accident I have discovered that this is only happening if we are using FastMM. If I switch to the standard memory manager the problem goes away.

Make sure that the byte arrays that you are transferring are initialized to zero before you start adding data to them. This will help to prevent the error from occurring if there is any leftover data from the previous operation in the byte array.

Forum Jump:

Users browsing this thread: 1 Guest(s)