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
