Re: glib2.0 2.64.6-1 (TEST)

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug  4 18:04, Jon Turney wrote:
> On 26/07/2023 15:33, Corinna Vinschen wrote:
> > On Jul  3 15:49, Jon Turney wrote:
> > > On 02/07/2023 15:30, Jon Turney wrote:
> > > > 
> > > > The following packages have been uploaded to the Cygwin distribution:
> > > > 
> > > > * libglib2.0_0-2.64.6-1
> > > > * libglib2.0-devel-2.64.6-1
> > > > * libglib2.0-doc-2.64.6-1
> > > > 
> > > [...]
> > > > 
> > > > There are many test-suite failures, however, as far as I can tell, they
> > > > are not regressions, so this should work as well as it ever did.
> > > 
> > > At least some of these test failures are due to bugs or shortcomings in the
> > > Cygwin DLL. In an ideal world, I'd have the time and motivation to
> > > investigate them all, but here's a brief summary of the few I looked into
> > > ...
> [...]
> > > 
> > > all the GDbus tests: these seem to get stuck during the handshake for an
> > > emulated unix-domain socket, somehow (It seems like all the dbus pacakge
> > > tests fail also, probably in the same way)
> > 
> > Does an extra call to setsockopt(fd, SOL_SOCKET, SO_PEERCRED, NULL, 0)
> > fix this, perhaps?
> > 
> 
> I don't quite understand where this call is supposed to go? In the client?
> in the listener?

Yes, both.  This switches off the handshake before calling connect or
accept.

> Isn't SO_PEERCRED only valid with getsockopt()?

Not after Christian Franke ported postfix to Cygwin back in 2014,
see commit 697b9afe00c21, especially the new comment in setsockopt.

The whole problem stems from the fact that we need to know that the
partner on the other side is a local Cygwin process and that it's
also an AF_UNIX emulation.  To accomplish that, Egor Duda introduced
the connect/accept handshake in commit 619f7fa0324c0 back in 2001.

The peercred stuff is in fact just some extra info we exchange during
that handshake, so maybe using SO_PEERCRED to switch off the handshake
was a bit weird.

If this is really the problem in your case, too, we should perhaps think
of a new solution to the problem we're trying to fix with the handshake.
I'm open to suggestions.

The unfinished work on fhandler/socket_unix.c using Windows Pipes was
one idea, but it's more complex than anticipated.  Another idea might
be to create a shared memory with a reproducible name, accessible from
both sides and used for the info handshake...


Corinna