PizzaProgram

I think I've found the leak. TCustomWSocket has this new property: FSessIpInfo : TIcsSessIpInfo; { V9.5 set by GetSocketIpInfo after connection or server WSAAccept method } Which has these 2: TIcsSessIpInfo = record { V9.5 used for WSocket SessionIpInfo property } SocLocalAddr: TSockAddrIn6; { family, address and port } SocRemoteAddr: TSockAddrIn6; Which are based on: sockaddr_in6 = record sin6_addr: TInAddr6; // IPv6 address Which has an array not freed at the end. in_addr6 = record case integer of 0: (S6_addr: array [0..15] of Byte); 1: (u6_addr8: array [0..15] of Byte); 2: (u6_addr16: array [0..7] of Word); 3: (u6_addr32: array [0..3] of LongWord); { V9.4 was integer } end;

I do not understand what you mean. I'm not "messing" with anything, simply providing a code to help those who want to decide where to put the SSL files instead of default path. Just like last time, I've shared the finished work. You may include it at your next release as an easy-to-use function, or as an example, or don't. Yes, there would be a great benefit to have all files extracted, what belong together. Just because ISC does not use it directly, we users do. 5300Kib or 6156Kib is less than 14% increase. Using an Exe-compressor first, like UPX would reduce it even more: Ultimate Packer for eXecutables Copyright (C) 1996 - 2025 UPX 5.0.2 Markus Oberhumer, Laszlo Molnar & John Reiser Jul 20th 2025 File size Ratio Format Name -------------------- ------ ----------- ----------- 875704 -> 351928 40.19% win32/pe openssl.exe Packed 1 file. In this case the increase of the .RC file would be: +6% only! Compared to the benefit to have an SSL all-in-one package, IMHO the difference between 5287Kib / 5630Kib is nothing. Also do not understand. Why do you think I did not used them at the end after I've found? I'm not "complaining" about anything! I'm very very glad You are upgrading, fixing ICS!!! If I would be a millionaire, I would donate you min $100.000 each year for this excellent work. I'm just writing here to tell, how to improve ICS with a few extra lines in the help file, so others do not need to spend 40minutes to found out what I did: <OFF> (Since I've never used any newer ssl than the ones already included at source: I've downloaded the openssl-3.5.4 zip, extracted only the dlls + the readme.txt, red the txt, found nothing, overwrote the dlls with new one in the ICS\ICS-OpenSSL\ directory, because I've thought that is how it has to be done, and completely overlooked the .RC files... and than tried to find out, why is it not working.) This sounds to You probably very stupid, because You wrote your own code and it is obvious to YOU, how to upgrade the ssl files. But it is not every time easy to follow the thought of an other programmer. </OFF> So +1 separated line here: https://wiki.overbyte.eu/wiki/index.php/ICS_Download at top of the SSL download table, and +1 line at the top of the readme.txt inside the ZIP would be very helpful. Like: INSTALL ======== To upgrade SSL files packed inside your EXE, simply overwrite the .RC + .RES + files inside this path: {yourcomponents}\ICS\Source\ The .RES file includes the 3 DLL + 2 TXT files + the version number it will be unpacked during runtime. Like: ..\3504\ Thank you in forward. Because I have know idea, where to even begin to fix it. As you see, I always share my code if I have found a solution for a problem. PS: - Why the hostile tone? Sorry, if my English is not perfect and my sentences are not polite enough, but I'm a simple programmer + company leader, not an English poet.

Memory leaks report: Since I've upgraded ICS from v9.1 to this new v9.5, there are: - 4 memory leaks reported every 100 seconds in OverbyteIcsWSocket.pas , Line 6931-6934 , these 4 lines generate it: FSessIpInfo.LocalAddr := WSocketSockAddrToStr(FSessIpInfo.SocLocalAddr); FSessIpInfo.LocalPort := IntToStr(Swap(FSessIpInfo.SocLocalAddr.sin6_port)); FSessIpInfo.RemoteAddr := WSocketSockAddrToStr(FSessIpInfo.SocRemoteAddr); FSessIpInfo.RemotePort := IntToStr(Swap(FSessIpInfo.SocRemoteAddr.sin6_port)); I know, that 3+12+5+7 bytes are not much, but it is spamming the "memory report" it generates. 😞

Just wanted to report that this code (I've published for v9.1), must be fixed too, since the Unit names changed : (and now you have to include both units in uses part in your source!) // Example code: how to set a path, where OpenSSL files get unpacked from .RES file compiled into your APP uses OverbyteIcsTypes, OverbyteIcsLIBEAY; ... p := exe_path + c_my_SSL3_base_dir; // 'e:\myApp\' + 'Bin\SSL\202xxxxx\' OverbyteIcsTypes.GSSL_PUBLIC_DIR := p; OverbyteIcsTypes.GSSL_DLL_DIR := p + '\3503'; // 'e:\myApp\Bin\SSL\202xxxxx\3503'; // add version number! // GSSL_SignTest_Check := True; // << if you enable this line, test it first! It works for me. try OverbyteIcsLIBEAY.IcsLoadSsl; Result := True; except on E:Exception do logme('Failed to initialize SSL3 DLLs. Error message: ' + E.Message); end; WARNING! 1.) The "openssl.exe" file is still not included in the .RES file, so you have to create a separate resource file for it, or download from somewhere elsewhere. (Recommended to: .ZIP or .7z it first, upload / download as a packed file, than unpack it locally, because the download of EXE files is usually blocked by the AV programs.) 2.) The version number gets loaded automatically from the .RES file! The path ending: \...\3503\ will be automatically created, based on the version. So, to upgrade to v3.5.4: Overwrite the .RC + .RES files inside \Source\ path, extracted from: 'openssl-3.5.4-win32.zip' . (This is not written / explained inside the ZIP's readme.txt .)

<OFF> Wow! Great job! Did not know SVN has support for MQTT too. @AndrzejBluszcz Just a question: Why Delphi? Most people use Node-RED for managing MQTT embedded devices. (Don't get me wrong, I love Delphi! Just interested on ...) Are you using this lib ?

I would like to ask for a tiny help, because I do not know ICS well enough yet to find a solution for this... 👼 I've switched from Indy to ISC a few weeks ago. It runs only on a few PCs yet so I can test it's durability. But it's not stable enough yet, because sometimes, when the server is temporary overloaded I experience a strange behaviour: (By "sometimes" I mean after a few days of run. So I can not debug it, only read the logs of clients on remote PCs.) 1. failing attempt: httpGET: Error #8 -- Request aborted on timeout 2. attempt: (after 20 sec) 0 byte answer, no error msg. 3., 4., 5., ... all the attempts after that: httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup httpGET: Status #404 -- Cannot change SocketFamily when not closed or in DNS lookup ... forever ... and the only way I can fix it, by restarting the program. Here I've shared my code using TSslHttpCli before: I was told not to destroy and recreate ICS component every each time before using it, like I did with Indy. But in that case: Why ICS does not reset itself / the socket, after first (timeout) error ? Do I have to create: some kind of "onTimeout" function for it manually, and close the socket myself? (I'm guessing that the socket is still open, and that's why it's causing trouble to re-connect. Right?) Why does my function's Result is True after such error, while the "error" text is clearly showing there was a big problem with the request? (The only case this can happen, if Statuscode is 200 or 400. Not #8 or none or #404.) Do I have to set: SslHttpCli3.StatusCode := 0; each time myself before calling .GET ? (Otherwise I do not see, why I do get a "True" as result.) Thank you very much in forward for any insight / help / idea !🙂

Closing the socket every each time before a new REST request, kills the concept of : "do not have to re-re-re-reconnect to the same server and re-re-reinitialize SSL". I think it would be logical to keep the socket as long as it works, (sometimes for days), but kill it when there was an error. That was my question about: Do I have to take care of that manually by default? Or did I find a bug in the component that is very hard to reproduce? How about something like this? try SslHttpCli3.StatusCode := 0; SslHttpCli3.Get; except on E:Exception do begin errorTxt := E.Message; try SslHttpCli3.CtrlSocket.Close; except end; end; end;

OFF: 📴 I absolutely agree, that it is very hard to apply new features, while maintaining backward compatibility. @EugeneK I was also freaked out from this change, took me 40+ work-hours to realize, debug, understand and adapt my code to it. It would have been nice, if it would have appeared first only as an OPTION, (disabled by default,) with a big fat red warning on the main page, that the next release will be default to this behaviour, so all of us could have been prepared... But now I like it. It's a great new feature. Resolves a huge problem: - "How to download DLLs from internet from a https site, without SSL DLLs present." So I'm very grateful to the developer maintaining and improving this component, and sharing it with us! 🌞

I have a huge app (pizzaprogram) running for 20+ years rock stable on hundreds of PCs, written in Delphi7, using: AlphaSkin + Indy + UIB + TVirtualStringTree also had 5 background threads running without any problems. (Some of them are using UIB.) This year I've started to work with `OverbyteIcsSslHttpRest, OverbyteIcsLogger, OverbyteIcsSslJose, OverbyteIcsSslX509Utils, OverbyteIcsWSocket, OverbyteIcsSuperObject, OverbyteIcsHttpProt, OverbyteIcsUtils, OverbyteIcsSSLEAY` units, running in a 6th separated thread. Since then, every 1-6 hours my program is crashing with EOutOfResources whenever AlphaSkin is trying to create or resize a bigger Bitmap. I've upgraded AlphaSkin from 2019 version to latest, but it did not help. (Actually it made it even worth, because the new version is generating 32bit bitmaps for every form and panel and button forehead.) The private memory consumption of my EXE is always under <150MB , usually 75MB Peak Virtual memory size < 300MB GDI number < 900 Please give me some hint / advice, how could I solve this mystery?

[Final Solution] <= v9.1 There must be 4 things manually programmed, to prevent memory violation when running ICS (SSL CLI) in background threads: Set MySslHttpCli.MultiThreaded := True; Create one global component in the main-thread at program start, and initializing OpenSSL3 DLLs from there. OverbyteIcsLIBEAY.IcsLoadSsl(); Destroy that global component only at program end. (This way OpenSSL can stay in memory, and initialized only once.) Create and initialize ICS components only inside the EXECUTE method of background threads ! (Otherwise the web-calls will still run in the main thread. Reason: ICS is uning Window handles.) Recommendation: - Create a fail safe code inside procedures where get / post etc is being called: if GetCurrentThreadId <> SslHttpCli3.ThreadID then raise Exception.Create('! ERROR ! SslHttpCli component of ICS is called from a different Thread! Not the one it was created: ' + IntToStr(SslHttpCli3.ThreadID)); ... until next release of ICS (>= 9.2? ) does it automatically.

I've finally finished to rework all my codes, so it works both with old Indy OpenSSL 1.0.2 and latest ICS 9.1 (OpenSSL 3.2) by setting a simple checkbox (UseSSL3?) But when I test it, it gives odd results, because it takes 3x so much time to download a simple XML with ICS now. Old Indy download time = 560 - 570ms New ICS download time = 1560-1580ms I have tested it many many times, same results. - Both components running in background thread. - BasicAuth (username + password) is used. - Indy component is getting created each time before download. But ICS (+SSL initialization) is done only once before thread start. The code I use is very simple: function Get_with_SSL3(const url: string; SslHttpCli3: TSslHttpCli; var Data:TMemoryStream; var error: string; timeOut: integer): Boolean; var size: Int64; begin Result := False; if Data = nil then Data := TMemoryStream.Create; SslHttpCli3.URL := url; SslHttpCli3.Timeout := timeOut; try try SslHttpCli3.Get; except on E:Exception do // 400 error := E.Message; end; finally Result := (SslHttpCli3.StatusCode = 200) or (SslHttpCli3.StatusCode = 400); size := 0; try if Assigned(SslHttpCli3.RcvdStream) then begin SslHttpCli3.RcvdStream.Seek(0, soFromBeginning); size := SslHttpCli3.RcvdStream.Size; end; if size > 0 then begin Data.Clear; Data.LoadFromStream( SslHttpCli3.RcvdStream ); end else error := 'ERROR! 0 byte answer. ' + error; except on E: Exception do hiba := '! Stream read error: ' + CRLF + E.Message; end; if Assigned(SslHttpCli3.SendStream) then SslHttpCli3.SendStream.Size := 0; if Assigned(SslHttpCli3.RcvdStream) then SslHttpCli3.RcvdStream.Size := 0; end; end; Is this "normal" ?

I would like to report once again: - Since the last 14 days NO MORE PROGRAM ERRORS occurred any more caused by ICS running in background thread . - running on 100+ PCs I strongly suggest implementing those 3 fail-safe lines of codes at the next release, to prevent such behaviour ! (Because it took me 8+ month and many gray hair to find out what's causing it and how to fix it. Also there is no written warning about these anywhere.)

Dear @Angus Robertson , 🙂 Where You able to fix the problem by: - Renaming the openssl.exe to openssl-x64.exe for the 64 bit version - Leaving openssl.exe for 32 bit. (because it's compatible with both) This way even if you copy the content of the 32 + 64 bit ZIP files together, the one will not overwrite the other! (As it happened during preparing this 9.1 ZIP file on your PC.) Re-creating the v9.1 ZIP would be nice too, but at least prepare the: v9.2+ please, (so such overwrite never happens again.) Calling a 32bit exe on a 64bit OS is not a problem. (But the other way around it is bad.) TODO: - Copy both EXE files (openssl.exe + openssl-x64.exe) to the (next) ZIP files, you release. Thank You in forward!

What I still don't know: Should I set myGlobalMainCLIcomponent.MultiThreaded := TRUE; for the Main thread's component too ? Or only for those running in the background thread ?

Well, I'm shocked. You were right! I've moved the creation of the components from the initialization part to the Execute procedure and It's the same fast now as Indy. Also this will probably explain WHY my application crashed always ... (link to prev. topic about this problem) Thank you very much for the help! I truly recommend, the future versions of the component should check, and raise an error if: The creation and running thread are not the same? The first initialization (of loading SSL DLLs) and final destruction is not running in the main thread! Property of .Multithreaded is True while running in a background thread? (Can be automated too.) It's not just me, who recommended that:

Thanks for all the answers ! To clarify things: Yes, I create those components in the background threads. Each thread = each separate http component. 👼 No, it would be a big mistake to put everything in the main thread. 🤯 This is a POS program with a max user-response time of 50-100ms of the Main thread. (And there are 4-5 background threads doing different things, like DB-locking, DB-searching, DB-executing+ commiting + order cashing, menu-syncing, Logging, CallerID, Syslog, etc. So blocking the main thread would be more than problematic.) Seriously, I do not try to blame anybody, both components are excellent works ! Congrat to both of you and I'm really glad I can still use my old delphi7 for such complex things, like web-server + https. But that time increase from 580ms to 1560 is not normal, and I'd like to dig to the bottom of it. - Is there something maybe misconfigured? - Why does the 2th, 3th, etc call of ICS taking the same time as the 1th? I do not destroy the component, do not tell it to disconnect, so the socket should be established to the same domain, only some sub-parameters of the URL is changing ! So theoretically the speed should shorten after the first connection. - Opening the URL in a browser: Firefox time measure shows = 560ms too, so that is the standard server response time. - (Ping to the server is constant 2ms)

A Solution would be in the next release: (9.2 ?) - Please rename that openssl.exe to: openssl-64.exe - and include the 32bit exe in the component-pack-ZIP too please ! - Even better, if both EXE files would be also auto-embedded, just like the DLLs. They are small compared to the whole directory combined. Thank You all for the help!

Thank you very much for the quick replay! I've double checked, and triple checked, and realized, you where right! About the problem, why I was mislead: On this site: https://wiki.overbyte.eu/wiki/index.php/ICS_Download There is only one ZIP available of 9.1 download for Delphi7. Inside that ZIP there is only one ICS-OpenSSL folder. (Containing both 32bit and 64bit DLLs.) Inside that folder there is only one openssl.exe file. (No separate 32/64bit versions of it.) I've also checked, who made the digital signature for DLLs and the EXE: - They are signed by the same company (Magenta Systems Ltd) nearly the same time. (21 sec. difference) I've also checked the other ZIP made for new Delhpi versions: https://wiki.overbyte.eu/arch/icsv91-new.zip But there is exactly the same structure. So basically NOTHING IS INDICATING, that this exe is only for 64 bit ! But if I scroll down to the bottom of the page and download the binary file separately : https://wiki.overbyte.eu/arch/openssl-3.2.1-win32.zip That openssl.exe has a smaller size! (814k)

I know! That's why do not understand, why this new openssl.exe is behaving differently?

Thank You very much for trying to help, but I'm talking about hundreds of PCs, that needs to use this exe every few year once to generate new keys. Deploying all those missing DLLs by hand to every each PC one by one would be an insane big task. If there are 32 bit normal DLLs present in the same directory, the EXE should have had recognise and use those, just like it did before this new version. Of course, as a programmer myself, I can make some "dirty hack-solutions" to circumvent the problem, (which will probably cause other problems,) but it's just not the way it should work! 😞

But now I have found a new problem with latest release: openssl.exe is not running on Win10 64bit PC, if only the 32bit DLL-s are present ! (This problem did not occure on prev. versions.) - What can I do? - Is there any "command line switch" to force search for the 32 bit DLLs ? (My app is 32 bit, I have now all the 32bit DLLs embedded into into, taking already lot's of space.)

... fixing the PATH problem was easy, ... p := exe_path + c_my_SSL3_base_dir; OverbyteIcsSSLEAY.GSSL_PUBLIC_DIR := p; OverbyteIcsSSLEAY.GSSL_DLL_DIR := p + '\2301'; // 'e:\myApp\Bin\SSL\202xxxxx\2301'; // add version number // GSSL_SignTest_Check := True; try OverbyteIcsLIBEAY.IcsLoadSsl; Result := True; except on E:Exception do logme('Failed to initialize SSL3 DLLs. Error message: ' + E.Message); end;

Yes, I fully understand all of it now. Thanks for the replay! The only 4 things are not yet clear to me: 1.) What is the command I can force this "unpacking" (+ initialization) of the resource-embedded DLLs ? 2.) Can I set a path before where is should happen? (I like to put those to my own APP's dir, like: MyExePath\Bin\SSL\20240205\dll ) 3.) ... If I want to do that, should I disable: {DEFINE OpenSSL_ProgramData} ? 4.) After resource unpacking / before each initialization if these DLL files: - Is ICS checking the file's integrity? (CRC32 or at least the size?) (Because I could list many cases when it does not succeed. (Write error, bad Antivirus program, modified by a malware, ... )

... hmmm that's interesting: Since the upgrade from v9.0 -> to v9.1 My EXE file (compiled under Delphi 7 ) increased from: 15.5 MB -> to 20.5 MB I'm using MPress to self-compress it, and it also shows a +21% size increase: 7.1 MB -> 8.6 MB That's a huge difference if we count that only pure code happened. (No new pictures added or similar, which would explain it) Well, it is not a very big problem, but there are still some restaurants having only 30-60Kbit internet max. (3G) ... and also a memory consupmtion on a Win32 tablet is +25% more. ... Investigating it further I've realized, there are new huge .RES files in the source directory. LibV32OpenSSL32.RES And so I've realized what all that means: I have red about in the 9.1 " what changed " topic, but did not comprehend, that the section: "Distribution of the ICS OpenSSL files has changed " is an extreamly cool upgrade Maybe re-writing it using my own words can help others too: The new 9.1+ ICS will force-include OpenSSL DLL files inside the compiled EXE by default. - It will extract these DLL files from the EXE on first run / initialisation to a common directory. - This behaviour can be turned off by editing the ...\ICS\Source\Include\OverbyteIcsDefs.inc file. - But it's not recommended because some features will fail to work.