Named pipe failure, multithreading and asynchronous I/O

[FPiette 382]

Hello,

 

I have an old and excellent code by Russell Libby dated back to 2003 which I updated in 2013 for current Delphi (XE5 at that time).

The code is working well for all Delphi XE versions and also for Delphi 10. Starting from Delphi 10.1 up to current Delphi 10.3.1 Rio, the code is broken. It compile fine but stay blocked at runtime.

 

The blocking occurs in the server code, when an asynchronous I/O against a named pipe that is supposed to be finished. (Line 2710 in Pipes.pas, call to GetOverlappedResult).

 

I tried several hours to debug the code, comparing what happen with Delphi 10 (Working) and Delphi 10.3.1 (not working), without success.

I suspect something with multithreading more than with asynchronous I/O.

 

I'll be happy if someone has an idea or - even better - has a look at the source code (attached).

To test the code, compile and run the server, then the client. On the client, click connect button, then click send button. You'll see data sent by the client into the server window if it works. If it doesn't work, no data displayed on the server Window and the process has to be killed by task manager.

 

Regards,

François Piette

Embarcadero MVP

 

PipesRussellLibby.zip

[Attila Kovacs 629]

It works fine on Berlin U2.

 

Edit: 10.3 CE too.

Edited March 24, 2019 by Attila Kovacs

[FPiette 382]

I confirm it work on 10.1 Berlin 32 bit.

I confirm it doesn't work on Rio 10.3 Update 1 (Version 26.0.33219.4899). That is what is required for me. I was testing previous versions in the hope to find out what was broken at some point.

 

Best Regards,

François PIETTE

Embarcadero MVP

 

 

[Guest]

Couldn't reproduce here, Delphi 10.3 Update 1, Version 26.0.33219.4899 - seems to work as expected

[miab 25]

He works for me on 10.3.1 Rio Win32

Studio 10.3 Version 26.0.33219.4899

[Allen@Grijjy 44]

Worked for me with 10.3 on Win32.

[FPiette 382]

Thanks for all having tested. It definitely doesn't work here.

Just to be sure: it compile fine but at runtime, the server hang on receiving message. So are you sure you tested at runtime and successfully sent a message (In the edit box) from client to server? (Instruction in my first message above).

My tests are done on Windows 7 up-to-date.

 

Thanks.

 

[Attila Kovacs 629]

I'm pretty sure. Win10

[miab 25]

Indeed, it does not work on Windows7-64 pro, but works on Windows10-64 pro (Delphi 10.3.1-Win32)

Edited March 26, 2019 by miab

[Attila Kovacs 629]

I can't recompile it on w7 but the exes are working just fine in a w7 VM for me.

[Alexander Elagin 143]

Does not work here when compiled with Delphi 10.1 (Win 7 Pro x64) with the same symptoms - server hangs. But works perfectly when compiled with Delphi XE in the same environment.

Edited March 26, 2019 by Alexander Elagin
Tested with XE.

[Sherlock 663]

Works here with 10.3.1 on a Win10-64 VM.

Must say however that on a Win7-32 VM only the connection seems to work. Server and client state a connection has been made, but after that no messages are received on either side. No hanging though!

[FPiette 382]

OK, Sherlock and Alexander confirm it doesn't work. Sorry for the other, but I fear they confused being able to compile (That works everywhere) and correct execution (Message sent from client is visible on server).

 

Now the real question: what has changed in Delphi that make it fail now while it worked for year, until Delphi 10.1 in fact. I think it ois a threading issue but not sure. I tried to debug the code but was not able to see anything obviously wrong (And it isn't since it worked up to Delphi 10.1 so it is clearly soothing related to Delphi itself).

 

Any help to find out the issue is really appreciated.

 

Regards,

François Piette

Embarcadero MVP

 

[Allen@Grijjy 44]

I tried it both inside the debugger and outside the debugger with 10.3 with Win32 on Windows 7.  At first it didn't work at all, as you described.  Then it suddenly started working after I tried solution #1 in this article, https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/Install-Failure-Error-997-Overlapped-I-O-operation-is-in-progress.html

 

Now I am not so sure why it started working and I cannot stop it from working, go figure.

 

Since I know you are skeptic of actually running and testing on Win7, I attached a screenshot.

Edited March 26, 2019 by Allen@Grijjy

[FPiette 382]

Hi Allen,

 

Thanks a lot for having taken time to look for my issue. I gave a try to your solution and unfortunately it doesn't work here.

 

I wonder why, if it is a Windows update issue, the application compiled with an older Delphi is working!?

I have read the KB2918614 update description designated as the culprit by the article you mention. I don't see anything related to the present issue. I fear about broking something elsewhere if a rename the folder as described.

 

Best regards,

François Piette

 

[FPiette 382]

I have done an intensive debug session and found the issue although I don't understand why it works with older Delphi versions.

At line 2710, where the server hang, we have the code:

Result := GetOverlappedResult(FPipe, FOlapRead, FRcvRead, TRUE);

I simply changed the last argument by FALSE like this:

Result := GetOverlappedResult(FPipe, FOlapRead, FRcvRead, FALSE);

And now it works!

That last argument when TRUE tells GetOverlappedResult to wait until completion. If FALSE, it returns immediately with whatever data is available, setting FRcvRead variable with actual number of bytes read.

Since we only go to that code line when data is available, because of WaitForMultipleObjects called at line 2939, we can safely don't wait for more data.

 

I will do more testing with the actual - real world - application using that code. In case the issue persist, I will report it here.

 

Thanks to all having participated in this conversation.

--

François Piette

Embarcadero MVP

 

 

[Jacek Laskowski 57]

21 hours ago, FPiette said:

Thanks to all having participated in this conversation.

--

François Piette

Embarcadero MVP

 

 

 

Will this project be publicly available in a repository?

 

[FPiette 382]

2 hours ago, Jacek Laskowski said:

 

Will this project be publicly available in a repository?

 

It is already available in my blog for years: http://francois-piette.blogspot.com/2013/04/inter-process-communication-using-pipes.html

[Jacek Laskowski 57]

 

2 hours ago, FPiette said:

It is already available in my blog for years: http://francois-piette.blogspot.com/2013/04/inter-process-communication-using-pipes.html

I try download from your site, but I get error:

 

 

 

Access denied

The requested URL cannot be provided

http://www.overbyte.eu/cgi-bin/redirect1<...>

Blocked by Web Anti-Virus

Reason: threat of data loss

Detection method: cloud protection

[FPiette 382]

Sorry to hear that.

I tried right now and it works perfectly. According to the message you get, this message comes from your "Web Anti-Virus". I don't know this product but for sure it is the culprit. I suggest you disable it.

Also note that the source code is attached to my first message in this thread.

[Jacek Laskowski 57]

I'm sorry, actually a browser-side problem, my antivirus (kaspersky) has blocked the call. It's kind of weird because I've had this antivirus for two years and I have never heard such a message.

[Jacek Laskowski 57]

On 3/27/2019 at 6:05 PM, FPiette said:

I will do more testing with the actual - real world - application using that code. In case the issue persist, I will report it here. 

 

Did testing show any additional problems? Is it possible to safely use the library in production?

[Guest]

I do understand why you want to pipes for legacy stuff.

But can i ask why for new projects? Isn't the socket APIs "localhost" better (way more versatile)?

My apologies if this is too OT.

[Jacek Laskowski 57]

Are the pipes obsolete and not recommended?

[Remy Lebeau 1392]

1 hour ago, Jacek Laskowski said:

Are the pipes obsolete and not recommended?

Not at all.  They are a perfectly valid, and still fully-supported, form of IPC.

 

The only reason I have ever had to choose sockets over named pipes is security (or lack of) and ease-of-coding.  Pipes are securable objects (from the OS's perspective), sockets are not, which can make deployments and configurations a little easier to work with.  And pipes can be a little trickier to code for than sockets.  But pipes work just fine when used correctly.

Edited May 14, 2019 by Remy Lebeau