Re: Patch request to qt 5.9.4
- Date: Wed, 13 Mar 2019 01:33:31 -0700 (PDT)
- From: Mark Geisert <mark@xxxxxxxxxx>
- Subject: Re: Patch request to qt 5.9.4
On Wed, 13 Mar 2019, Tatsuro MATSUOKA wrote:
I have prepared binaries:
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
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple