glib is trying to move toward using microseconds-in-gint64 as its
universal time format.
No real API breaks here since GTimeSpec is new this unstable release
series.
Otherwise, attempting to create a GSocketConnection from the socket
will likely return the wrong type, since the protocol won't match any
of the registered subtypes.
Also add the start of a GSocket test program (from davidz).
https://bugzilla.gnome.org/show_bug.cgi?id=627171
This way, if g_socket_connect() is called with a GProxyAddress,
g_socket_get_remote_address() will later return that same address.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk>
This patch fixes this problem
Syscall param socketcall.sendmsg(msg.msg_control) points to uninitialised byte(s)
at 0x3D5B00EA60: __sendmsg_nocancel (syscall-template.S:82)
by 0x53F9790: g_socket_send_message (gsocket.c:2918)
by 0x540FDD0: g_unix_connection_send_credentials (gunixconnection.c:351)
by 0x542B93F: _g_dbus_auth_run_client (gdbusauth.c:618)
by 0x5438001: initable_init (gdbusconnection.c:2191)
by 0x53E09CC: g_initable_init (ginitable.c:105)
by 0x543F6E9: g_bus_get_sync (gdbusconnection.c:6091)
by 0x402C7E: test_connection_life_cycle (gdbus-connection.c:126)
by 0x4C7CABB: test_case_run (gtestutils.c:1174)
by 0x4C7CD84: g_test_run_suite_internal (gtestutils.c:1223)
by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
Address 0x7fefff9fc is on thread 1's stack
Signed-off-by: David Zeuthen <davidz@redhat.com>
Previously if a GSocketConnection had a blocking GSocket, it would
sometimes block during asynchonous I/O, and if it had a non-blocking
socket, it would sometimes return G_IO_ERROR_WOULD_BLOCK from
synchronous I/O. This fixes the connection to not depend on the socket
state.
https://bugzilla.gnome.org/show_bug.cgi?id=616458
- Make GCredentials instance and class structures private so it can't
be subclassed and we don't have to worry about ABI compat
issues. This also allows us to get rid of the GCredentialsPrivate
struct.
- Add a GCredentialsType enumeration that is used whenever exchanging
pointers with the user. This allows us to support OSes with
multiple native credential types. In particular, it allows
supporting OSes where the native credential evolves or even changes
over time.
- Add g_socket_get_credentials() method.
- Add tests for g_socket_get_credentials(). Right now this is in the
GDBus peer-to-peer test case but we can change that later.
- Move GTcpConnection into a separate gtk-doc page as was already
half-done with GUnixConnection. Also finish the GUnixConnection
move and ensure send_credentials() and receive_credentials()
methods are in the docs. Also nuke comment about GTcpConnection
being empty compared to its superclass.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Just because SOCK_CLOEXEC was defined at build time doesn't mean the
kernel we're running on supports it. So if socket() fails with EINVAL,
try again without the flag.
https://bugzilla.gnome.org/show_bug.cgi?id=624463
The GSocket docs point out that g_socket_send/g_socket_receive may
return G_IO_ERROR_WOULD_BLOCK even if g_socket_condition_check claimed
that they wouldn't. Fix the socket streams to check for that.
https://bugzilla.gnome.org/show_bug.cgi?id=603309
socket_strerror() was assuming all "strerror" messages are shorter
than 128 bytes, which is certainly true on Linux, but apparently not
on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=615494
The messages array was not reallocated correctly because it was using
malloc instead of realloc. Also, if the user requested messages but
none were received we would segfault. Rewrite the code to fix this
and, for better readability, use GPtrArray instead of rolling our own.
Also make the docs mention that the user need to free the returned
GSocketControlMessage objects using g_object_unref().
Clarify that *messages may be set to %NULL if there are no messages
(this will save pointless allocs of arrays).
Finally, the Win32 version didn't set messages to the expected value.
https://bugzilla.gnome.org/show_bug.cgi?id=616877
Signed-off-by: David Zeuthen <davidz@redhat.com>
There might be a GSource attached to a GMainContext, about to be removed by a
pending cancellation. Deleting the handle too early will trigger a g_warning in
the "select()" call in GMainContext. Attached patch fixes this by deferring
destruction of WSAEVENT object until GSocket's finalize().
Patch from bug #612702.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
g_socket_send_message() and g_socket_send_to() fail with ENOBUFS or
EFAULT due to the fact that if no "address" argument is specified to
g_socket_send_message, when g_socket_send_message() calls sendmsg(2),
the 2nd parameter to sendmsg ("const struct msghdr *msg") contains
uninitialized values. The fix is simple - initialize msg.msg_name to
NULL and msg.msg_msg_namelen to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=594759
Even though we ignore SIGPIPE, gdb will still stop when the process
receives one, which sometimes confuses people into thinking the app
has crashed (eg, bug 578984, bug 590420), and is annoying anyway. So
use MSG_NOSIGNAL if it's there.
http://bugzilla.gnome.org/show_bug.cgi?id=591378
Currently, to implement cancellability correctly, all synchronous
calls to GSocket must be preceded by a g_socket_condition_wait() call,
(even though GSocket does this internally as well) and all
asynchronous calls must do occasional manual
g_cancellable_is_cancelled() checks. Since it's trivial to do these
checks inside GSocket instead, and we don't particularly want to
encourage people to use the APIs non-cancellably, move the
cancellation support into GSocket and simplify the existing callers.
http://bugzilla.gnome.org/show_bug.cgi?id=586797
