Possible issue with 64bit Oracle

[aehimself]

Is this the record alignment we are talking about?

RecordAlignment.PNG

If this can be changed from project options it's not a bug, it was a decision by Embarcadero and we should use conditional directives to readjust our buffers accordingly - IF this is the only problem it is raising.

In the mean time I submitted my request to our legal team for a data extract of the table where the UTF16 issue can be reproduced. I'll keep you posted.

[miab3]

I think I found the AV reason for Delphi 11.1 sp1 Win64.
When ASLR is disabled, the error does not occur.
Here's more about it:
https://blogs.embarcadero.com/rad-studi ... ity-flags/
https://en.delphipraxis.net/topic/6627- ... ker-flags/
https://quality.embarcadero.com/browse/RSP-38488
"...It seems that casting as Integer worked while ASLR was disabled. Returned NativeUInt was probably < Max(Int). ASLR is now enabled by default (11.1)."

and

"There is a systematic crash here with Delphi 11.2 64 bit because of changes in ASLR support.
Please change in Vcl.Shell.ShellCtrls the types of TCustomShellTreeView.FImages, TCustomShellComboBox.FImages, TCustomShellListView.FLargeImages
and TCustomShellListView.FSmallImages from Integer to THandle"

See if disabling ASLR will improve.

Michal

[miab3]

https://en.delphipraxis.net/topic/6627- ... ment-57456

[miab3]

https://stackoverflow.com/questions/745 ... ead-on-x64

[MJFShark]

We seem to have gone a bit afield from my post about this record alignment memory allocation bug. Note that this ASLR stuff doesn't relate to that particular issue. If there are problems in Zeoslib that are "solved" by turning off ASLR, then there are probably pointers that are being cast as integers. I have not noticed that in my testing btw. As I mentioned in that thread from last year, testing with FASTMM's allocate TOPDOWN feature is another way to catch them. If we had a sample app (like the console app I posted) it would really help diagnose any issues, perhaps in a new thread so we can focus on it.

-Mark

[miab3]

Hi MFJShark,

Have you checked if your errors persist after disabling ASLR and rebuilding the entire ZEOS and application?

Michal

[aehimself]

Have you checked if your errors persist after disabling ASLR and rebuilding the entire ZEOS and application?

I reproduced an issue in a 32-bit test application which is not affected by ASLR. Mark's right and it might be related to record field alignment - this can be easily confirmed by changing it in compiling options.

I'll put together a new test app to try this.

[miab3]

Hi, aehimself,

I see you didn't fully understand what the ASLR error is.
It is revealed in Win64 mode due to not quite correct use of types (which work properly in Win32).
A number of libraries in recent months had to be corrected (released version take into account ASLR inclusion in Win64)
that previously seemed to work correctly in Win64, and they started throwing errors after enabling ASLR by default in Delphi.


Michal

[MJFShark]

You are both correct. The memory error I reported is just a simple instance of record alignment. It's not mysterious in any way and a simple sizeof shows the difference in memory sizes. ASLR (or topdown memory allocation as I mentioned in that thread) can help to point out issues where pointers (or often handles) are being handled as 32bit integers. It's a technique I used heavily when converting stuff from 32 to 64bit and is definitely worth looking at. I know of no general issue with ASLR, I've used it for years before it became the default with no issues... or I should say, no issues that were not of my own making lol!

-Mark

[miab3]

Apropos ASLR in 32-bit mode:
"...Note: {$HIGHENTROPYVA} is only available for 64-bit Windows. Default {$HIGHENTROPYVA ON}
Delphi 11.2 expands ASLR support for the Win64 platform. It adds the ability to randomize memory addresses at high locations. This makes 64-bit applications really take advantage of the full address space.

Note: This configuration might require you to clean up some of your code according to 64-bit rules..."
https://docwiki.embarcadero.com/RADStud ... 4-bit_ASLR

Michal

[MJFShark]

Note: This configuration might require you to clean up some of your code according to 64-bit rules..."
https://docwiki.embarcadero.com/RADStud ... 4-bit_ASLR

Michal

Could you expand on the "note" part of this? I'd love to know what clean-up you're referring to? Or is it in the documentation you linked? I didn't see it. Thanks!

-Mark

[miab3]

This is in the Embarcadero documentation.
In the previous links were discussed what to pay attention to.

Michal

[miab3]

https://en.delphipraxis.net/topic/7968- ... ally-work/

https://security.stackexchange.com/ques ... d-dep-work

https://learn.microsoft.com/en-us/cpp/b ... w=msvc-170

Michal

[MJFShark]

If there's something that needs to be looked at related to this (and it's one of the drivers I use), I'll be happy to take a look. Perhaps it should be a new thread since it's not related to the bug I noted.

-Mark

[marsupilami]

I found out what's causing this particular heap issue. In AllocateOracleSQLVars it dynamically allocates memory for the TZSQLVars record, but I think it's assuming that the record is packed and so the allocation doesn't take into account the record field alignment setting (which defaults to Quad word in recent versions of Delphi.) Regardless, the issue can be "fixed" for now by just allocating more memory.
So change

Code: Select all

Size := SizeOf(ub4) + Max(1,Count) * SizeOf(TZSQLVar);

to

Code: Select all

Size := (2 * SizeOf(ub4)) + Max(1,Count) * SizeOf(TZSQLVar);

But note that that assumes Delphi's default quad word alignment. I'll do some more testing and see what else I can find.

-Mark

Hello Mark,

I tried to look into this but it seems that the TZSQLVars never get in touch with any oracle function? So the memory alignment of TZSQLVar shouldn't be a problem.
Maybe have a place where we go beyond the reserved memory because we don't respect the count of the variables we registered the memory for?

Best regards,

Jan