Web lists-archives.com

Re: Patch request to qt 5.9.4




On Wed, 13 Mar 2019, Tatsuro MATSUOKA wrote:
[...]
 I have prepared binaries:
 http://tmacchant3.starfree.jp/gnuplot/Eng/cyg_qt_test/

 test
 From gnplot prompt

 gnuplot> set terminal qt
 gnuplot> plot x

 Without Qt patch

 Could not connect to existing gnuplot_qt. Starting a new one.

 Warning: slow font initialization



 With Qt patchplot appears
[...]
One note: for gnuplot.exe and gnuplot_qt.exe, debug symbols are not stripped and 
you can trace gdb but I did not know debug info for Qt.

I believe I've found the root cause of this issue of outbound connect on a non-blocking socket not working under Cygwin.

It's in Qt's qlocalsocket_unix.cpp. On line 285 there's a call to qt_safe_connect(). At this point the socket fd has already been set non-blocking. Within qt_safe_connect() there's a call (eventually) to Cygwin's connect(). That connect() is returning -1 with errno set to EINPROGRESS.

Back in qlocalsocket_unix.cpp, line 287 does a 'switch(errno)' but doesn't
have a case for EINPROGRESS.  That error condition reaches the 'default:'
case, returning without the connection being completed. I don't know why there's no error report to the user.

Note that you don't want to quick-fix this by adding a 'case EINPROGRESS:'
that simply acts like the connection is completed. I think somebody who knows Qt network internals will have to develop a real fix.

It seems nobody has run across a non-blocking connect() that doesn't immediately complete connection.. but Posix mandates an EINPROGRESS error in that situation so Cygwin appears to be doing the right thing.

..mark
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple