Strage Access Violation with high memory usage (64 bit)

[marder]

Hi.

I am using TeeChart Pro (2013.08.130521) with Delphi XE2.

I have seen an access violation in my 64 bit compiled application, when the application uses quite much memory.

The call stack shows some tee chart components:
http://download.jam-software.de/treesiz ... lstack.txt

Could you please take a look at the call stack and let me know what you think about it?
Thanks and best regards!

[Yeray]

Hi,

What are the chart characteristics when the crash occurs?
We'd need a simple example project so we can reproduce the problem here. Looking at the stack trace it seems the application crashed when drawing the foot title shadow. However, we'd need to debug an application to see in what circumstances does it happen.

Also, looking at the stack trace it doesn't look as an out of resources problem, does it?

physical memory : 11262/16091 MB (free/total)
allocated memory : 2,30 GB

[marder]

Hi.

I fear this is a bit more complicated.
I have no sample which can be used to reproduce this issue. It only occurred twice and we do not know the steps to reproduce.

I hoped that you could show me any direction where I could take a look at to find the reason for this.

Anyway, I will let you know in case we have a repro for this issue.

Best regards!

[marder]

Hi.

I do still have no simple demo project for this issue, but I now used the source code of the latest beta version () and I got a new call stack (including line numbers this time):
http://download.jam-software.de/treesiz ... tack_2.txt

Could you please take a look at this new call stack and the related source code?
Maybe you will get a new idea how this could happen.

Any help would be good.
We could also try out any patches you might think of.

Thanks and best regards!

[marder]

Hello.

I was now able to reproduce this issue in my IDE


I noticed that here the local variable IBackLines32 has strange values from the 3rd entry (see image below).

I then searched inside the code and found some castings from Integer to Pointer, which is incorrect for 64 bit builds.
See here one example (TeCanvas.pas, line: 1637):


Note: Pointer in 64 bit applications is not a 32 bit integer value, but a 64 bit integer value.
To work in both, 64 and 32 bit applications, you should consider using NativeInt instead.

Please let me know what you think about this.
best regards

[Narcís]

Hello marder,

Note: Pointer in 64 bit applications is not a 32 bit integer value, but a 64 bit integer value.
To work in both, 64 and 32 bit applications, you should consider using NativeInt instead.

Thanks for your feedback! Yes, you are right. We are going to change it immediately.