Dalija Prasnikar

The whole world does it is not much of an argument. Anyway, Android Studio is a Java application and it is rather memory hungry. Just starting it will gobble up 500MB of memory. Opening very small project will raise that to 1.5 GB. Comparing to Delphi which uses 116 when started and about 400MB when you open small project (similar to one in AS). So Delphi with opened project consumes less memory than AS without any. When you build that small project in AS it will go over 3 GB like it is nothing. Of course it only comes in 64-bit variant. macOS OS has been only 64-bit for over a decade. They have been pushing all applications to 64-bit from the very start and since 2019 macOS no longer supports running 32-bit applications. It is wonder they lasted that long as Apple is not much concerned with backward compatibility and the ability that their customers can run something or not. Or whether they will be forced to buy new hardware. Actually everything Apple does is to force people to buy new hardware. Visual Studio got 64-bit version less than 2 years ago. If the MS with all their resources haven't done that before nor though it was absolutely necessary, then certainly there is no reason why Embarcadero would have to jump into 64-bit immediately. I am not going to comment Lazarus, as I don't know to much about it. I seriously doubt MS would do that. Maybe when they switch to 128bit Windows.

Even if this particular piece of code is the same, some other part critical for reproducing the issue might be different. So knowing the Delphi version is always important.

Instantiating TRttiContext at the beginning would not help in this case as the problem is in additional lazy loading. Also not creating global TRttiContext is also affected. Whatever you do it will be broken. However, depending on the Delphi version you are using, creation of global TRttiContext solves some other threading issues. And it is also faster than doing create... try..finally.. free approach. You can patch System.Rtti to fix the issue.

I reported the issue as https://quality.embarcadero.com/browse/RSP-42359

First of all, when asking about particular issue specifying Delphi version is mandatory. System.Rtti is being updated for literally every release (including updates). If you want us to comment on source code we need to make sure that we are looking at the same code. The code in question is perfectly fine. But the whole thing is broken in another place. Namely procedure TRttiInstanceType.ReadPropData; and other similar methods which use boolean for checking, but without double checked locking. This can causes calling LazyLoadAttributes twice which then can corupt the whole thing in that code. For instance I would get a crash on nil Finalizer instance. if FReadPropData then Exit; p := PByte(TypeData.PropData); TMonitor.Enter(Package.FLock); try // Here we would need to check FReadPropData again end exit if it is true classic := ReadClassicProps; ext := ReadExtendedProps; FProps := SubtractClassic(classic, ext); FAttributeGetter := LazyLoadAttributes(p); FIndexedProps := ReadIndexedProps; FReadPropData := True; finally TMonitor.Exit(Package.FLock); end; end;

This is not encoding, this is visual representation. Underlying encoding (numbers) is the same.

There is still a lot of code running in that thread that we haven't seen and don't know how it interacts with other code and might cause memory corruption for various reasons. But the string encoding/decoding code we have seen is not it, no matter how outdated or not.

Delphi can perfectly handle pizza slice emoji with either UTF8String or WideString. How do you think it was handling Chinese characters that were spanning two UTF-16 code units? Unicode encoding is a standard no matter what OS you are using. The most that can happen is that you cannot properly display the character because you are lacking appropriate font. Now I cannot claim that Delphi 7 encoding/decoding functions are capable of handling all those correctly as I haven't tried, but even in Delphi 7 those functions could be replaced with the ones that handle them properly.

True, but, UTF16 is either one or 2 of 16bit units ( it is called unit in Wikipedia), so it is either 2 bytes or 4 bytes, why this wasn't ever a problem with all versions of Delphi ?, What problem? In context of wide string we can talk about wide characters where each such character stores one 16-bit code unit. This is important for determining the length of the wide string which is measured in number of wide characters - 16-bit code units. So full Unicode character can be stored either in single or two 16-bit wide characters, which means that for characters that span two wide characters reserved space will be 2 * 3 which is more than enough to store that whole Unicode character in UTF8 representation which can be maximum 4 bytes. There is no Unicode character that fully fits into single 16-bit code unit that requires more than 3 bytes when encoded in UTF8. I have no idea what you want to say here. I really looked and looked then looked again, i just don't see failing point in both functions Utf8Encode and UnicodeToUtf8, this UnicodeToUtf8 though does trim but never fail, will return 0 if the input is an empty string other than that it will trim the result according to supplied buffer if it is shorter than needed, but will not fail. I was in a hurry and I took wrong turn while looking at code. Yes, you are right, the conversion function does not fail. The main point still stands and it does not cause buffer overrun. And again coming from UTF8Encode, conversion buffer allocates enough space for successful conversion of WideString content. So the bug in the code we are discussing here does not come from handling strings and their buffers, at least not in the code that was presented here.

The function is not wrong. If Unicode character would require 4 bytes in UTF8 encoding, then it would also require two wide characters (UTF16 encoding) which means reserved number of bytes for such character would be 2 * 3 = 6. Also if the supplied buffer is not enough then the called conversion function would fail (without causing buffer overrun) and would return 0 and such scenario is fully covered by UTF8Encode function.

That would not happen since they support C++ in Android Studio. And such compiled code is no different than Delphi code.

Yes, there is a UTF8String in Delphi 7. That is not what character means. It is how much code units are required for encoding Unicode code point in specific encoding. Unicode character is called a code point and depending on encoding each code point can occupy from 1 to 4 bytes https://stackoverflow.com/questions/2241348/what-are-unicode-utf-8-and-utf-16 Character in Delphi can have different meanings: One is Char type which can have size of one or two bytes depending on Delphi version (pre 2009 or 2009+). There are also other character types which can have different byte sizes. Another one is used in terms of character type used in various string types: character size for AnsiString and UTF8String in all Delphi versions is one byte, for default string type in pre Unicode versions size of character is one byte, for Unicode versions size is two bytes. Length function always returns the size in characters for particular string type which means the actual number of bytes will depend on the character size for that string type. for UTF8String length will always equal the number of bytes because size of character in UTF8String is one byte, regardless whether some Unicode characters (code points) require more that one byte when encoded. Yes it is. Just call the Length function on it. You only need to consider how many bytes are in codepoint if you are parsing such data byte by byte, where accessing UTF8String by index will not necessarily give you complete information about Unicode code point stored as you will get only one byte of it.

UTF8String is always one byte per char, regardless of a Delphi version.

Yes, you are right. I am trying to solve one problem, while forgetting the broader picture. Although it might be easier to figure out what is wrong if the thread would just stall, comparing to having random issues somewhere else in the application.

Those few cycles mean nothing comparing to constructing the whole component over and over again. So this kind of safeguard can be easily implemented without having any negative side effects. The property itself could be left as-is, but initial value can be set in constructor depending on the thread ID value: FMultiThreaded := TThread.CurrentThread.ThreadID <> MainThreadID;

Well, that is rather unfortunate design choice as it can be easy for users of a library to overlook this requirement. Wouldn't it be better to autodetect whether component is created within background thread and set that property automatically rather than manually?

You can find more information in this thread

You need to recompile your application with the latest Delphi 11.3 and submit that to Play Store See: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Supported_Target_Platforms#cite_note-11.3-1

If the issue happens only when background thread is running, then background thread creates a problem. This sounds like memory issue, if FASTMM is not registering the leak, you are probably allocating and holding on to some memory that accumulates inside the thread. Another potential issue without a visible leak could be a memory fragmentation and then you have an issue when you try to allocate larger block of memory like bitmap.

Yes. I started with explanation how to approach memory allocation issues (since you mentioned FASTMM), but I should have been more clear that this part is most likely not related to your current issue.

It means that either code in the GUI or the code in thread is exhausting the memory. So you need to know which one causes the problem if you want to locate it. For start, just comment out all the code in thread and see how application behaves, then you can start turning on parts of the code in thread until you hit the issue. There is plenty of code we don't see here so it is hard to say what is the problem. Just because FASTMM does not show the leak that does not mean that there is no memory leak, it is just that it is not classical memory leak where you allocate memory and you don't release it. Another form of a leak is that you keep allocating memory and holding on to it even after you no longer need it. such memory will be properly released on application exit, but while running application can still exhaust all available memory. BTW, some of your code in thread is not properly handling allocations/deallocations. You have try...finally blocks that do more than they should, you don't protect all allocations with try block - the other option, would be to initialize all object instances to nil first, and you have unnecessary Assigned checks before calling Free which can safely run on nil object instances. All that tells me that your memory management code is not exactly stellar and that you probably similarly poor code in other parts of your application. So chances are rather high that your code somewhere in your application is causing you a trouble and that it has nothing to do with ICS alone. However, EOutOfResources error is not about a memory allocation but leaking GDI objects. Those leaks will not be reported by FASTMM. Because it is wrapped inside GDICheck it is possible that there is no leak at all, but some other GDI error.

chatGPT I would like to see that one working... https://meta.stackexchange.com/a/391067/313443

Stack Overflow has a good system with casting flags where certain amount of flags automatically deletes the post. Flags are available based on reputation to prevent abuse and bad flags cause flagging suspension. Also moderators can issue manual suspension. Because we are small forum, you could even manually give such delete flag capabilities to trusted users where you know they will not be abused and automatically delete posts even with single flag. There is enough of us to keep the site clean, the only thing needed is infrastructure that would allow that.

I will have to change my position. I was focused on behavior where compiler would catch all cases where record would be uninitialized - by all I don't mean having different code paths where compiler cannot easily determine whether something is initialized or not even for types it currently shows warnings. To catch all such cases, calling record method would also need to show a warning, but there is no way compiler can differentiate between method that initializes a record and method that expects already initialized method - the difference between imagined TGuid.Clear and TGUID.IsEmpty. However, for other value types calling a method does not trigger a warning and simply disables further warnings, so such behavior could be easily extended to non-managed fields in records without causing any bogus warnings and would not be any more difficult to achieve than existing warnings for other value types. It is likely that variant parts in records would have to be excluded as accessing and initializing one field does not mean that another field that shares same memory would be fully initialized (memory overlap can be only partial) and it is possible that tracking sizes and what is initialized and what not would be too much in such scenario. There is a value in showing at least some warnings comparing to none.

I think there was some article about C# covering similar area that explained the problems rather well. I cannot find it now.