Davide Angeli

Hi, I'm using TIdFTP to transfer a 100Mb file on a FTP server on cloud. This process always worked fine. Now I've upgraded to D10.4.2 (I'm using INDY distribute with Delphi). I don't know what is changed now (if something on Delphi, on Indy or something on the FTP server) but now at the end of the file transfer, in the TIdFTP.FinalizeDataOperation the program raises an EIdReadTimeout executing this instruction: ... GetResponse([226, 225, 250]); ... The file seems transferred regularly. There is only something wrong in the finalizing operation. Attached there is the log file produced with TIdLogFile. There is something that I could do or that I could check to avoid this timeout? Thanks Davide installa.exe.log

Thanks you just put me on the right path! IdFTP.NATKeepAlive property was already set in my application but probably with wrong parameters, maybe an IntervalMS too long. I've recalibrated the parameters (IdleTimeMS = 30000 and IntervalMS = 10000) and now it seems working properly (no read time out anymore). Sorry I'm not a "Wireshark guru" it's the second time for me using it! I've to say that is not so easy to use. I've found how to isolate FTP commands directed to the FTP server IP address but even if the size has reduced, 100 mb still remains. Perhaps it can be reduced more but it is not necessary.

I've monitored with WireShark both Filezilla and TIdFTP transfer. I've attached the final part of the transfer of both. I did these tests one after the other. I really don't know why this is happening. I've done a test with Total Commander too and also with this tool there are non timeout problems. Why TIdFTP doesn't receive the answser and waits for a timeout? I could not attach the 2 wireshark log here because they are about 500Mb (but if it could be usefull I could upload it somewhere).

Hi Remy, I've just simulate that transfer with Filezilla (3.52.2) and it works fine (no timeout error)... Just retried TIdFTP and unfortunatly with it the timeout is still present (I was hoping it might be a temporary internet connection problem but it doesn't seem to be the case). Attached is the filezilla log if could help. In it I could see a message "226 transfer complete" after the send data. This message is missing in IdFTP log... filezillatransfer.log

I think is something related to use with c++. For me is irrelevant because I'm using only Delphi Pascal Compiler.

In my case I've solved unchecking the "Dual Packages" option in the 64 bit page

Same problem here... I just download latest JCL from github to upgrade it. Win32 goes fine but when the installer starts to compile win64 I got this: Could it be related to latest hotfixes?

Same here. Yesterday LSP/Codecompletion doesn't work the whole morning (close/reopen ide multiple times, rebuild every library etc but nothing) then I closed a couple of source files in the IDE's editor and it start to work again! Another amenity of yesterday, debugging a 64bit delphi application the IDE consumed all my PC memory (8Gb on 16Gb used by the ide alone!). This obviously crashed the whole system making debugging impossible. Closed the IDE and redone the operation everything worked regularly. They are not insurmountable problems but they are very annoying because they are continuous.

After several days of working with the 3 patches applied I have to say that things are going better but 10.4.2 is still far to be a stable environment to work (in my configuration). Even if with less frequency I continue to have scattered errors in the IDE: - access violations in dcc32270.dll (usually compiling a project not active and always need to close/kill ide when happen because of cascade of access violations) - access violations in rtl270.bpl (switching between projects / closing the ide) - "Error reading Image1.Picture.Data" doing text search in ide editor I think/hope that embd should/could invest some time to make things better for those who work with project groups and runtime packages.

After a day of testing the update I make some considerations on the subject of this conversation: the internal error situation has definitely improved. Now in my case I have a more stable situation again. Let's say that in my opinion this bug has exacerbated the underlying problems that exist in the management of Delphi project groups. I always work with an open group of projects and sometimes it happens, despite being positioned on a project, to compile another one (for example a dll used by the active project); I do it with the right click selecting the project in the project window. In this case, despite the patch, it has already happened to me a couple of times that the IDE went into error (an access violetion in dcc32270.dll) and then if I return to compile the active project I get the internal error in question again. However these now seem sporadic cases probably linked to internal problems in switching on the fly from one project to another.

I raccomend this too because in the first time I tryed to apply te patch I selected YES and one of the patches was not applied. After strange errors (red text in cmd prompt) I read the patch logs and I discovered the the second patch did nothing but both of them result installed in the getit manager. So I unistalled both e reinstalled both selecting "NO" when getit ask me to close the IDE. Now I did the same with the third patch. This way of applying patches via getit is terrible but after few attempts I got the job done... I raccomend also to pay attention to UAC prompt that in my case does not appear on top: I was waiting to the patch apply and because it tooks tool long (cmd window opened doing nothing) I noticed on the task bar the flashing icon of the UAC prompt.

I completely agree. I can't understand why I have to change my infrastructure (used for decades) just because Embd broke the toy ... For a thousand reasons that I am not going to list I absolutely do not want to have a mega gigantic single exe. After all, how is Delphi made? Isn't it an exe that makes extensive use of dll bpl files? It would be like telling someone who wants to use Ms Word not to use docx files use only plain text files because docx do not work and crash the program! If creating programs that run bpl and dll is not a recommended practice, Embd has to declare it out of the product box!

Excuse me but I'm just curious to understand in which kind of situations the IDE fails like in mine... Which kind of projects are you working on? A singole exe file? My main projects have all a structure of a main exe, 3/4 runtime packages (common to every project) and several dll's. I'm daily working with project groups. Every piece (exe, bpl, dll could be compile in 32 or 64 bit).

I've only projects that use packages... Top priority correction for me is an hot fix released in a couple of days not one released in more than a couple of months!

I am baffled and pissed, here time flies and still no answer or solution from Embarcadero! I cannot understand why they are not giving top priority to correct these problems. It's unbelievable ... Daily work in these conditions is a nightmare! But is there anyone using 10.4.2 without problems? Has anyone switched to this shameful bug-ridden version to work seriously? Am I the only fool?

Same for me. It is why I discarded the idea of using MSBuild to solve the problem. I absolutly need a full functioning debugger to work. We need Embarcadero fix ASAP!!!

It would be nice as you can see here, almost a month ago, I gave my full availability also for remote assistance if necessary but no one took me into consideration...

Yes it would be nice... I'm locked because in my case the internal error is systematic at every new compile. In the next few days I have to decide if I can continue with 10.4.2 or if I have to switch back to 10.4.1. I've wasted a lot of precious time with this issue and my boss is not really happy... In my situation with 10.4.2 the dailywork is a real bloodbath. I think the worst release ever in terms of productivity. I really love Delphi (I'm using Delphi since release 1!) but it is not acceptable to wait months to have fixed bugs of this magnitude.

"Failed to load ssleay32.dll" I did a file search on my develop system just now and I could see dozens of OpenSSL versions on it ... I suppose that some of it is loaded before the one that I want, so I forceed the path with IdOpenSSLSetLibPath(mypath) and now it works fine without errors. Just for knowledge, after search I could see that libeay32.dll+ssleay32.dll are present also in "c:\Program Files (x86)\Embarcadero\Studio\21.0\bin\subversion\" even if this release is not the last "1.0.2u" but it is the "1.0.2n". Yes it work Thank you

Hi, I'm trying to use the latest Open SSL available on GitHub (1.0.2u) and using it with Indy included in 10.4.2 but I get always an exception that Indy "Could not open SSL library". I'm using it on a SMTP connection. Before the exception I get a messagebox with the message that is impossible to find the ordinal 4684 in the ssleay32.dll... Is this (1.0.2u) the right DLL to use with Delphi 10.4.2? Thanks

I have opened the QC to create a new report but I see that someone has already done so: https://quality.embarcadero.com/browse/RSP-33425 Hope this could be solved quickly because it is really impossible to work in this way.

Hi, after several test I've tryed also this one and I could see that this kind of internal error is an access violation in BDS.EXE: First chance exception at $08343340. Exception class $C0000005 with message 'access violation at 0x08343340: read of address 0x00000018'. Process bds.exe (12984) Analizing the "Modules" window I see that that address refers to dcc32270.dll. I've attached a screen shot. Is this one helpfull for someone to discover the problem? I'm not capable to analize further.

Same here... the last week I've dedicated almost my time to found a workaround but I'm still fighting. Now I'm trying to reorganize and simplify the structure of my program and doing some cleanup as @FredSsuggested, to see if things get better.

It's hard... the project is quite complex with several runtime packages

I agree... Just cleaned up the system: manual Delphi uninstall + registry cleaned + delete all embarcadero files on system + all bpl, dcp, dcu... Fresh install from web installer this time (last one was from ISO). Installed only the Windows platform (no linux, no android, no ios etc) Installed only third parts components needed by my projects For now not installed expertes/toolas (MMX, GExpert etc) THE PROBLEM STILL PERSISTS! I think that these random errors could be related to same bug: sometimes "Access violation at address 0BAF903E in module 'dcc32270.dll'. Read of address A2DCF46C." sometimes in place of the internal error F2084, I get this: "[dcc32 Fatal Error] aaaaa.pas(27): E2411 Unit bbbbb in package cccccc refers to unit ddddd which is not found in any package. Packaged units must refer only to packaged units" often I get also "Access violation at address 50060148 in module "rtl270.bpl". Read of address 3C49FAC4" I don't know what to do at this point... I'll open a ticket on QC, but honestly, not being able to reproduce the case in a small test project, I doubt it will be considered.