Kas Ob.

@PizzaProgram Good luck ! Not only for that 😎, also for a slice of pizza 🍕

OK, i don't want this to as debate, but few things here should be pointed, 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 ?, The is : simply because all the input and output where either internally generated data or by the OS ( mostly Windows), Windows API always refer to them as Wide, anyway this shouldn't a problem as long as the input and output is from Delphi application or the Windows, but in this very case the data are coming from remote place over the wire who knows the origin, also being handled by OpenSSL, so assuming it is will be 2 bytes UTF8 or even 2 bytes UTF16 is at least doubtful. 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. It would be very helpful if someone paste the code of these functions here, of course if that not violating some license.

How is this not wrong if this function assumes a UTF8 char can be only 3 bytes max instead of 4 ? What else is wrong with that conversion function, have you seen these two calls in one line of code, are we juggling strings left and right through many types from WideString, AnsiString then UTF8String with wrong max length and expect it to not be wrong, because it does work sometimes ?

I think you are following the wrong thing here, even if this problem caused by loading and unloading OpenSSL which i doubt, but yet you can just log the loading and unloading operations with their result to a file and be sure. If my hunch is right and it is caused by the intense allocating and reallocating operation done by both AlphaSkin and ICS with OpenSSL, then minimizing these operation by caching objects and reusing will only minimize the effect and delay the inevitable, this bug is just like ticking bomb and you were unlucky enough that is not crashing sooner. I don't have My Delphi 7 at hand so checked an old projects and looked at the code without even running it, and here saw this gem In Utf8Encode there is this Length * 3, which assuming the size of UTF8 char would be 3 bytes at max, among this pasta with a call to WStrToPChar, which is mindboggling in the middle of converting a string to convert it first then convert it again, it seems Delphi 7 may be wrong in handling UTF8, it is +20 after all, and the fact UTF8String is used as RawByteString, raise even more questions. Now assuming ICS (with dropped Delphi 7 support) is right and not missing with such conversion, i suggest you try the following 1) Use UnicodeToUtf8 and Utf8ToUnicode directly instead of Utf8Encode and Utf8Decode. 2) Use more aggressive memory manager to detect corruption, really you should try EurekaLog, it is the best ability to all sort of memory malpractices along with leaks resources like GDI handles. 3) Log all the strings in raw format to a file, write them to a a memorysteam separated with some chars then flush that stream to the disk, se for yourself the result. Hope that help.

+1

Yes. Using remote Delphi debugger or using different debugger to get these addresses will be way more accurate and easier. This one is the best out there https://x64dbg.com/

Also was there a UTF8String in Delphi 7 ? and how it being handled in , what did Length() return, length in bytes or in chars ? I have no idea.

May be, ! I might be wrong here but there is bug with string copying somewhere.

No ! The thing is : the bug might be not in this code you pasted and could be in other places even may be in ICS , Delphi 7 is not supported and things might be missed, also your suggestion of this "-1" explain that you need to research the difference between string (default) with WideString and AnsiString and UTF8String .. Here if UTF8 is 2 bytes per char then it should be or to make it safer when you are in doubt then, hard to me to advice this but but as i said the problem might be not only here (i mean these 2 lines), you have to research and understand these strings and their size then adjust your code accordingly. While i can't be sure 100% it is the problem but with high confidence it is the culprit but overflowing memory write.

I think screenshot would helped earlier, so others here could spot the problem for you, look at these is that what do you see ? The first one is an new project while the second has this So i think you are following the wrong thing, as many tools are build for Windows binaries with PDB debug information, in this case it could find a suitable address (previous with an export or known from the debug info) so it grabbed the closest before the address and resolved it as entry point. Find the culprit address by calculating the address of TMethodImplementationIntercept +xxxxxx then follow it in you debugger, or attach a debugger or... may be try Andres PDB debug info tool see if that works with your watching tool, or find another tool that does show an address instead of a relative address ... Hope that helps, and good luck.

This AlphaSkin is innocent here, though these leaks is definitely GUI objects, they are not freed and most likely with not closed handles. How this happen is easy to explain (i think), your introduced code most likely copied and pasted form ICS demos (assuming) but in all cases you are missing the part of converting and adjusting the read size for those strings, hence you are overflowing buffers and writing in places you should not, and because FastMM allocate memory once and reuse its parts will allow such overflow, also both AlphaSkin and ICs( the way you are doing it by not caching and reusing components) have very memory intensive operation, the code keeps overflowing and destroying GUI handles and may be other things, and that making AlphaSkin after each failed operation to respawn/recreate these handles and allocate memory on them. ps: many of the OpenSSL objects have zeros in its contexts or will be zeroed for security reason, so the overflow is writing 0's which make AlphaSkin think it is not allocated objects and not throw an exception.