Hi!
Compile a 64 bit exe. If you export a huge grid (with memory occupation of more than 4 gb) to XLSX file, you will get an AV at the end of the export procedure.
I have had a look at the code and maybe there is a bug in the unit cxExport:
Delphi[..]
TcxCacheCellStyle = packed record
[..]
Format: Integer;
[..]
end;
[..]
and in the unit dxXLSXExport (line 2112) the record is used in this way:
Delphi[..]
with StyleCache.GetStyle(I)^ do
Format := TdxSharedObject(Format).Index;
[..]
This cast can cause an AV in a 64 bit environment.
I was not able to reproduce this behavior. Attached is an example that works as expected on my side. Please modify it to illustrate the problem and attach it to your next message. We will examine it and do our best to find a solution. I am looking forward to hearing from you.
Ok , I'll try to create a test application for you. In the meanwhile I've found another bug in the unit dxXLSXExport.
Line 2104 should be changed in this way to prevent another AV when memory allocated is more than 4 gb:
AStyle.Format := NativeInt(AStyles.Add(ASharedStyle));
The previous existing cast to integer is incorrect in a 64 bit environment.
I am afraid it is not clear to me how to reproduce this issue. It would be of great help if you provide a sample project where this problem is reproducible.
Hi Mikhail, here is the sample application. It must be compiled in XE3 for windows 64 bit.
Click on the button "Fill memory" and then to "Export". Please be patience as it could take a long time to fill the memory (it took a night on my pc): it creates a lot of TcxLabel to pump up the application private bytes but it is necessary to raise the memory occupation over the $FFFFFFFF location to show the error.
I can also send you the Eurekalog call stack of the first AV if you need it.
TIA,
Domenico
Hello Domenico,
Thank you for your clarifications and sample. I am forwarding this issue to our developers for further processing.
You will receive an automatic message once the status of this issue is changed.