mirrors/wayland
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/wayland/wayland.git synced 2025-10-29 05:40:16 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
wayland/tests/connection-test.c

910 lines
23 KiB
C
Raw Normal View History

tests: Add connection tests
2012-03-02 23:42:46 -05:00
/*
* Copyright © 2012 Intel Corporation
*
tests: Update boilerplate from MIT X11 license to MIT Expat license Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2015-06-10 02:57:59 -07:00
* Permission is hereby granted, free of charge, to any person obtaining
* a copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
tests: Add connection tests
2012-03-02 23:42:46 -05:00
*
tests: Update boilerplate from MIT X11 license to MIT Expat license Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2015-06-10 02:57:59 -07:00
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial
* portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
tests: Add connection tests
2012-03-02 23:42:46 -05:00
*/
Add support for signed 24.8 decimal numbers 'fixed' is a signed decimal type which offers a sign bit, 23 bits of integer precision, and 8 bits of decimal precision. This is exposed as an opaque struct with conversion helpers to and from double and int on the C API side. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-05-08 17:17:25 +01:00
#include <math.h>
tests: Add connection tests
2012-03-02 23:42:46 -05:00
#include <stdio.h>
#include <stdlib.h>
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
#include <stdarg.h>
(multiple): Include stdint.h Some headers and source files have been using types such as uint32_t without explicitly including stdint.h. Explicitly include stdint.h where appropriate. Signed-off-by: Yong Bakos <ybakos@humanoriented.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
2016-07-18 12:42:25 -05:00
#include <stdint.h>
tests: Add connection tests
2012-03-02 23:42:46 -05:00
#include <string.h>
#include <assert.h>
#include <sys/socket.h>
#include <unistd.h>
#include <errno.h>
connection-test: Test fd transport
2012-03-24 14:27:30 -04:00
#include <sys/types.h>
#include <sys/stat.h>
connection-test: add tests for closure leaks When we destroy closure, we are leaking memory sometimes. Signed-off-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2014-12-19 14:53:03 +01:00
#include <poll.h>
tests: Add connection tests
2012-03-02 23:42:46 -05:00
tests: fix make check for out-of-tree builds It was failing with missing include files. While here, destroy the ugly "../src/..." include paths used in the tests that was just hacking around this problem in the Makefile: sed -i s/..\\/src\\/// tests/*.c
2012-06-15 22:44:28 +00:00
#include "wayland-private.h"
tests: Add connection tests
2012-03-02 23:42:46 -05:00
#include "test-runner.h"
connection-test: add tests for closure leaks When we destroy closure, we are leaking memory sometimes. Signed-off-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2014-12-19 14:53:03 +01:00
#include "test-compositor.h"
tests: Add connection tests
2012-03-02 23:42:46 -05:00
static const char message[] = "Hello, world";
static struct wl_connection *
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
setup(int *s)
tests: Add connection tests
2012-03-02 23:42:46 -05:00
{
struct wl_connection *connection;
assert(socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, s) == 0);
connection: Dynamically resize connection buffers When using fixed size connection buffers, if either the client or the server is sending requests faster than the other end can cope with, the connection buffers will fill up, eventually killing the connection. This can be a problem for example with Xwayland mapping a lot of windows, faster than the Wayland compositor can cope with, or a high-rate mouse flooding the Wayland client with pointer events. To avoid the issue, resize the connection buffers dynamically when they get full. Both data and fd buffers are resized on demand. The default max buffer size is controlled via the wl_display interface while each client's connection buffer size is adjustable for finer control. The purpose is to explicitly have larger connection buffers for specific clients such as Xwayland, or set a larger buffer size for the client with pointer focus to deal with a higher input events rate. v0: Manuel: Dynamically resize connection buffers - Both data and fd buffers are resized on demand. v1: Olivier 1. Add support for unbounded buffers on the client side and growable (yet limited) connection buffers on the server side. 2. Add the API to set the default maximum size and a limit for a given client. 3. Add tests for growable connection buffers and adjustable limits. v2: Additional fixes by John: 1. Fix the size calculation in ring_buffer_check_space() 2. Fix wl_connection_read() to return gracefully once it has read up to the max buffer size, rather than returning an error. 3. If wl_connection_flush() fails with EAGAIN but the transmit ring-buffer has space remaining (or can be expanded), wl_connection_queue() should store the message rather than returning an error. 4. When the receive ring-buffer is at capacity but more data is available to be read, wl_connection_read() should attempt to expand the ring-buffer in order to read the remaining data. v3: Thomas Lukaszewicz <tluk@chromium.org> Add a test for unbounded buffers v4: Add a client API as well to force bounded buffers (unbounded by default (Olivier) v5: Simplify ring_buffer_ensure_space() (Sebastian) Co-authored-by: Olivier Fourdan <ofourdan@redhat.com> Co-authored-by: John Lindgren <john@jlindgren.net> Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by: Manuel Stoeckl <code@mstoeckl.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: John Lindgren <john@jlindgren.net> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net> Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
2021-09-25 22:34:44 -04:00
connection = wl_connection_create(s[0], WL_BUFFER_DEFAULT_MAX_SIZE);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(connection);
return connection;
}
TEST(connection_create)
{
struct wl_connection *connection;
int s[2];
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
connection = setup(s);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
wl_connection_destroy(connection);
connection: Leave fd open in wl_connection_destroy Calling close() on the same file descriptor that a previous call to close() already closed is wrong, and racy if another thread received that same file descriptor as a eg. new socket or actual file. There are two situations where wl_connection_destroy() would close its file descriptor and then another function up in the call chain would close the same file descriptor: * When wl_client_create() fails after calling wl_connection_create(), it will call wl_connection_destroy() before returning. However, its caller will always close the file descriptor if wl_client_create() fails. * wl_display_disconnect() unconditionally closes the display file descriptor and also calls wl_connection_destroy(). So these two seem to expect wl_connection_destroy() to leave the file descriptor open. The other caller of wl_connection_destroy(), wl_client_destroy(), does however expect wl_connection_destroy() to close its file descriptor, alas. This patch changes wl_connection_destroy() to indulge this majority of two callers by simply not closing the file descriptor. For the benefit of wl_client_destroy(), wl_connection_destroy() then returns the unclosed file descriptor so that wl_client_destroy() can close it itself. Since wl_connection_destroy() is a private function called from few places, changing its semantics seemed like the more expedient way to address the double-close() problem than shuffling around the logic in wl_client_create() to somehow enable it to always avoid calling wl_connection_destroy(). Signed-off-by: Benjamin Herr <ben@0x539.de> Reviewed-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2014-09-30 14:43:03 +02:00
close(s[0]);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
close(s[1]);
}
TEST(connection_write)
{
struct wl_connection *connection;
int s[2];
char buffer[64];
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
connection = setup(s);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(wl_connection_write(connection, message, sizeof message) == 0);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_flush(connection) == sizeof message);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(read(s[1], buffer, sizeof buffer) == sizeof message);
assert(memcmp(message, buffer, sizeof message) == 0);
wl_connection_destroy(connection);
connection: Leave fd open in wl_connection_destroy Calling close() on the same file descriptor that a previous call to close() already closed is wrong, and racy if another thread received that same file descriptor as a eg. new socket or actual file. There are two situations where wl_connection_destroy() would close its file descriptor and then another function up in the call chain would close the same file descriptor: * When wl_client_create() fails after calling wl_connection_create(), it will call wl_connection_destroy() before returning. However, its caller will always close the file descriptor if wl_client_create() fails. * wl_display_disconnect() unconditionally closes the display file descriptor and also calls wl_connection_destroy(). So these two seem to expect wl_connection_destroy() to leave the file descriptor open. The other caller of wl_connection_destroy(), wl_client_destroy(), does however expect wl_connection_destroy() to close its file descriptor, alas. This patch changes wl_connection_destroy() to indulge this majority of two callers by simply not closing the file descriptor. For the benefit of wl_client_destroy(), wl_connection_destroy() then returns the unclosed file descriptor so that wl_client_destroy() can close it itself. Since wl_connection_destroy() is a private function called from few places, changing its semantics seemed like the more expedient way to address the double-close() problem than shuffling around the logic in wl_client_create() to somehow enable it to always avoid calling wl_connection_destroy(). Signed-off-by: Benjamin Herr <ben@0x539.de> Reviewed-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2014-09-30 14:43:03 +02:00
close(s[0]);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
close(s[1]);
}
TEST(connection_data)
{
struct wl_connection *connection;
int s[2];
char buffer[64];
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
connection = setup(s);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(write(s[1], message, sizeof message) == sizeof message);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_read(connection) == sizeof message);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
wl_connection_copy(connection, buffer, sizeof message);
assert(memcmp(message, buffer, sizeof message) == 0);
wl_connection_consume(connection, sizeof message);
wl_connection_destroy(connection);
connection: Leave fd open in wl_connection_destroy Calling close() on the same file descriptor that a previous call to close() already closed is wrong, and racy if another thread received that same file descriptor as a eg. new socket or actual file. There are two situations where wl_connection_destroy() would close its file descriptor and then another function up in the call chain would close the same file descriptor: * When wl_client_create() fails after calling wl_connection_create(), it will call wl_connection_destroy() before returning. However, its caller will always close the file descriptor if wl_client_create() fails. * wl_display_disconnect() unconditionally closes the display file descriptor and also calls wl_connection_destroy(). So these two seem to expect wl_connection_destroy() to leave the file descriptor open. The other caller of wl_connection_destroy(), wl_client_destroy(), does however expect wl_connection_destroy() to close its file descriptor, alas. This patch changes wl_connection_destroy() to indulge this majority of two callers by simply not closing the file descriptor. For the benefit of wl_client_destroy(), wl_connection_destroy() then returns the unclosed file descriptor so that wl_client_destroy() can close it itself. Since wl_connection_destroy() is a private function called from few places, changing its semantics seemed like the more expedient way to address the double-close() problem than shuffling around the logic in wl_client_create() to somehow enable it to always avoid calling wl_connection_destroy(). Signed-off-by: Benjamin Herr <ben@0x539.de> Reviewed-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2014-09-30 14:43:03 +02:00
close(s[0]);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
close(s[1]);
}
TEST(connection_queue)
{
struct wl_connection *connection;
int s[2];
char buffer[64];
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
connection = setup(s);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
/* Test that wl_connection_queue() puts data in the output
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
* buffer without flush it. Verify that the data did get in
* the buffer by writing another message and making sure that
* we receive the two messages on the other fd. */
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(wl_connection_queue(connection, message, sizeof message) == 0);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_flush(connection) == 0);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(wl_connection_write(connection, message, sizeof message) == 0);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_flush(connection) == 2 * sizeof message);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
assert(read(s[1], buffer, sizeof buffer) == 2 * sizeof message);
assert(memcmp(message, buffer, sizeof message) == 0);
assert(memcmp(message, buffer + sizeof message, sizeof message) == 0);
wl_connection_destroy(connection);
connection: Leave fd open in wl_connection_destroy Calling close() on the same file descriptor that a previous call to close() already closed is wrong, and racy if another thread received that same file descriptor as a eg. new socket or actual file. There are two situations where wl_connection_destroy() would close its file descriptor and then another function up in the call chain would close the same file descriptor: * When wl_client_create() fails after calling wl_connection_create(), it will call wl_connection_destroy() before returning. However, its caller will always close the file descriptor if wl_client_create() fails. * wl_display_disconnect() unconditionally closes the display file descriptor and also calls wl_connection_destroy(). So these two seem to expect wl_connection_destroy() to leave the file descriptor open. The other caller of wl_connection_destroy(), wl_client_destroy(), does however expect wl_connection_destroy() to close its file descriptor, alas. This patch changes wl_connection_destroy() to indulge this majority of two callers by simply not closing the file descriptor. For the benefit of wl_client_destroy(), wl_connection_destroy() then returns the unclosed file descriptor so that wl_client_destroy() can close it itself. Since wl_connection_destroy() is a private function called from few places, changing its semantics seemed like the more expedient way to address the double-close() problem than shuffling around the logic in wl_client_create() to somehow enable it to always avoid calling wl_connection_destroy(). Signed-off-by: Benjamin Herr <ben@0x539.de> Reviewed-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2014-09-30 14:43:03 +02:00
close(s[0]);
tests: Add connection tests
2012-03-02 23:42:46 -05:00
close(s[1]);
}
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
tests: Test wl_argument_from_va_list connection-test.c did not cover wl_argument_from_va_list, so add one test that specifically tests this method. Signed-off-by: Yong Bakos <ybakos@humanoriented.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-11-23 07:38:01 -08:00
static void
va_list_wrapper(const char *signature, union wl_argument *args, int count, ...)
{
va_list ap;
va_start(ap, count);
wl_argument_from_va_list(signature, args, count, ap);
va_end(ap);
}
TEST(argument_from_va_list)
{
union wl_argument args[WL_CLOSURE_MAX_ARGS];
tests: Fix "new ID" type handling in argument_from_va_list test New IDs are internally dealt with as objects, however this test expected to deal with 'n' as the uint32_t type that's just seen through the wire. We should give it an object instead, and expect an object from it. https://bugs.freedesktop.org/show_bug.cgi?id=99899 Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Kalev Lember <kalevlember@gmail.com> Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
2017-02-23 13:47:41 +01:00
struct wl_object fake_object, fake_new_object;
tests: Test wl_argument_from_va_list connection-test.c did not cover wl_argument_from_va_list, so add one test that specifically tests this method. Signed-off-by: Yong Bakos <ybakos@humanoriented.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-11-23 07:38:01 -08:00
struct wl_array fake_array;
va_list_wrapper("i", args, 1, 100);
assert(args[0].i == 100);
va_list_wrapper("is", args, 2, 101, "value");
assert(args[0].i == 101);
assert(strcmp(args[1].s, "value") == 0);
va_list_wrapper("?iuf?sonah", args, 8,
102, 103, wl_fixed_from_int(104), "value",
tests: Fix "new ID" type handling in argument_from_va_list test New IDs are internally dealt with as objects, however this test expected to deal with 'n' as the uint32_t type that's just seen through the wire. We should give it an object instead, and expect an object from it. https://bugs.freedesktop.org/show_bug.cgi?id=99899 Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Kalev Lember <kalevlember@gmail.com> Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
2017-02-23 13:47:41 +01:00
&fake_object, &fake_new_object, &fake_array, 106);
tests: Test wl_argument_from_va_list connection-test.c did not cover wl_argument_from_va_list, so add one test that specifically tests this method. Signed-off-by: Yong Bakos <ybakos@humanoriented.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-11-23 07:38:01 -08:00
assert(args[0].i == 102);
assert(args[1].u == 103);
assert(args[2].f == wl_fixed_from_int(104));
assert(strcmp(args[3].s, "value") == 0);
assert(args[4].o == &fake_object);
tests: Fix "new ID" type handling in argument_from_va_list test New IDs are internally dealt with as objects, however this test expected to deal with 'n' as the uint32_t type that's just seen through the wire. We should give it an object instead, and expect an object from it. https://bugs.freedesktop.org/show_bug.cgi?id=99899 Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Tested-by: Kalev Lember <kalevlember@gmail.com> Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
2017-02-23 13:47:41 +01:00
assert(args[5].o == &fake_new_object);
tests: Test wl_argument_from_va_list connection-test.c did not cover wl_argument_from_va_list, so add one test that specifically tests this method. Signed-off-by: Yong Bakos <ybakos@humanoriented.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-11-23 07:38:01 -08:00
assert(args[6].a == &fake_array);
assert(args[7].h == 106);
}
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
struct marshal_data {
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
struct wl_connection *read_connection;
struct wl_connection *write_connection;
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
int s[2];
uint32_t buffer[10];
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
union {
uint32_t u;
int32_t i;
const char *s;
connection-test: Test fd transport
2012-03-24 14:27:30 -04:00
int h;
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
} value;
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
};
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
static void
setup_marshal_data(struct marshal_data *data)
{
assert(socketpair(AF_UNIX,
SOCK_STREAM | SOCK_CLOEXEC, 0, data->s) == 0);
connection: Dynamically resize connection buffers When using fixed size connection buffers, if either the client or the server is sending requests faster than the other end can cope with, the connection buffers will fill up, eventually killing the connection. This can be a problem for example with Xwayland mapping a lot of windows, faster than the Wayland compositor can cope with, or a high-rate mouse flooding the Wayland client with pointer events. To avoid the issue, resize the connection buffers dynamically when they get full. Both data and fd buffers are resized on demand. The default max buffer size is controlled via the wl_display interface while each client's connection buffer size is adjustable for finer control. The purpose is to explicitly have larger connection buffers for specific clients such as Xwayland, or set a larger buffer size for the client with pointer focus to deal with a higher input events rate. v0: Manuel: Dynamically resize connection buffers - Both data and fd buffers are resized on demand. v1: Olivier 1. Add support for unbounded buffers on the client side and growable (yet limited) connection buffers on the server side. 2. Add the API to set the default maximum size and a limit for a given client. 3. Add tests for growable connection buffers and adjustable limits. v2: Additional fixes by John: 1. Fix the size calculation in ring_buffer_check_space() 2. Fix wl_connection_read() to return gracefully once it has read up to the max buffer size, rather than returning an error. 3. If wl_connection_flush() fails with EAGAIN but the transmit ring-buffer has space remaining (or can be expanded), wl_connection_queue() should store the message rather than returning an error. 4. When the receive ring-buffer is at capacity but more data is available to be read, wl_connection_read() should attempt to expand the ring-buffer in order to read the remaining data. v3: Thomas Lukaszewicz <tluk@chromium.org> Add a test for unbounded buffers v4: Add a client API as well to force bounded buffers (unbounded by default (Olivier) v5: Simplify ring_buffer_ensure_space() (Sebastian) Co-authored-by: Olivier Fourdan <ofourdan@redhat.com> Co-authored-by: John Lindgren <john@jlindgren.net> Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by: Manuel Stoeckl <code@mstoeckl.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: John Lindgren <john@jlindgren.net> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net> Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
2021-09-25 22:34:44 -04:00
data->read_connection = wl_connection_create(data->s[0],
WL_BUFFER_DEFAULT_MAX_SIZE);
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
assert(data->read_connection);
connection: Dynamically resize connection buffers When using fixed size connection buffers, if either the client or the server is sending requests faster than the other end can cope with, the connection buffers will fill up, eventually killing the connection. This can be a problem for example with Xwayland mapping a lot of windows, faster than the Wayland compositor can cope with, or a high-rate mouse flooding the Wayland client with pointer events. To avoid the issue, resize the connection buffers dynamically when they get full. Both data and fd buffers are resized on demand. The default max buffer size is controlled via the wl_display interface while each client's connection buffer size is adjustable for finer control. The purpose is to explicitly have larger connection buffers for specific clients such as Xwayland, or set a larger buffer size for the client with pointer focus to deal with a higher input events rate. v0: Manuel: Dynamically resize connection buffers - Both data and fd buffers are resized on demand. v1: Olivier 1. Add support for unbounded buffers on the client side and growable (yet limited) connection buffers on the server side. 2. Add the API to set the default maximum size and a limit for a given client. 3. Add tests for growable connection buffers and adjustable limits. v2: Additional fixes by John: 1. Fix the size calculation in ring_buffer_check_space() 2. Fix wl_connection_read() to return gracefully once it has read up to the max buffer size, rather than returning an error. 3. If wl_connection_flush() fails with EAGAIN but the transmit ring-buffer has space remaining (or can be expanded), wl_connection_queue() should store the message rather than returning an error. 4. When the receive ring-buffer is at capacity but more data is available to be read, wl_connection_read() should attempt to expand the ring-buffer in order to read the remaining data. v3: Thomas Lukaszewicz <tluk@chromium.org> Add a test for unbounded buffers v4: Add a client API as well to force bounded buffers (unbounded by default (Olivier) v5: Simplify ring_buffer_ensure_space() (Sebastian) Co-authored-by: Olivier Fourdan <ofourdan@redhat.com> Co-authored-by: John Lindgren <john@jlindgren.net> Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by: Manuel Stoeckl <code@mstoeckl.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: John Lindgren <john@jlindgren.net> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net> Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
2021-09-25 22:34:44 -04:00
data->write_connection = wl_connection_create(data->s[1],
WL_BUFFER_DEFAULT_MAX_SIZE);
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
assert(data->write_connection);
}
static void
release_marshal_data(struct marshal_data *data)
{
connection: Leave fd open in wl_connection_destroy Calling close() on the same file descriptor that a previous call to close() already closed is wrong, and racy if another thread received that same file descriptor as a eg. new socket or actual file. There are two situations where wl_connection_destroy() would close its file descriptor and then another function up in the call chain would close the same file descriptor: * When wl_client_create() fails after calling wl_connection_create(), it will call wl_connection_destroy() before returning. However, its caller will always close the file descriptor if wl_client_create() fails. * wl_display_disconnect() unconditionally closes the display file descriptor and also calls wl_connection_destroy(). So these two seem to expect wl_connection_destroy() to leave the file descriptor open. The other caller of wl_connection_destroy(), wl_client_destroy(), does however expect wl_connection_destroy() to close its file descriptor, alas. This patch changes wl_connection_destroy() to indulge this majority of two callers by simply not closing the file descriptor. For the benefit of wl_client_destroy(), wl_connection_destroy() then returns the unclosed file descriptor so that wl_client_destroy() can close it itself. Since wl_connection_destroy() is a private function called from few places, changing its semantics seemed like the more expedient way to address the double-close() problem than shuffling around the logic in wl_client_create() to somehow enable it to always avoid calling wl_connection_destroy(). Signed-off-by: Benjamin Herr <ben@0x539.de> Reviewed-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2014-09-30 14:43:03 +02:00
close(wl_connection_destroy(data->read_connection));
close(wl_connection_destroy(data->write_connection));
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
}
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
static void
tests: Simplify connection tests a bit
2012-03-05 21:40:01 -05:00
marshal(struct marshal_data *data, const char *format, int size, ...)
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
{
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
struct wl_closure *closure;
tests: Fix signedness warnings
2012-04-13 10:11:11 -04:00
static const uint32_t opcode = 4444;
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
static struct wl_object sender = { NULL, NULL, 1234 };
tests: Simplify connection tests a bit
2012-03-05 21:40:01 -05:00
struct wl_message message = { "test", format, NULL };
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
va_list ap;
va_start(ap, size);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
closure = wl_closure_vmarshal(&sender, opcode, ap, &message);
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
va_end(ap);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
assert(closure);
assert(wl_closure_send(closure, data->write_connection) == 0);
wl_closure_destroy(closure);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_flush(data->write_connection) == size);
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
assert(read(data->s[0], data->buffer, sizeof data->buffer) == size);
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
assert(data->buffer[0] == sender.id);
assert(data->buffer[1] == (opcode | (size << 16)));
}
TEST(connection_marshal)
{
struct marshal_data data;
tests: Add more marshal tests
2012-03-05 21:53:38 -05:00
struct wl_object object;
struct wl_array array;
static const char text[] = "curry";
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
setup_marshal_data(&data);
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
tests: Simplify connection tests a bit
2012-03-05 21:40:01 -05:00
marshal(&data, "i", 12, 42);
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
assert(data.buffer[2] == 42);
tests: Simplify connection tests a bit
2012-03-05 21:40:01 -05:00
marshal(&data, "u", 12, 55);
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
assert(data.buffer[2] == 55);
tests: Simplify connection tests a bit
2012-03-05 21:40:01 -05:00
marshal(&data, "s", 20, "frappo");
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
assert(data.buffer[2] == 7);
assert(strcmp((char *) &data.buffer[3], "frappo") == 0);
tests: Add more marshal tests
2012-03-05 21:53:38 -05:00
object.id = 557799;
marshal(&data, "o", 12, &object);
assert(data.buffer[2] == object.id);
marshal(&data, "n", 12, &object);
assert(data.buffer[2] == object.id);
array.data = (void *) text;
array.size = sizeof text;
marshal(&data, "a", 20, &array);
assert(data.buffer[2] == array.size);
assert(memcmp(&data.buffer[3], text, array.size) == 0);
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
release_marshal_data(&data);
tests: Add connection marshalling tests
2012-03-03 00:29:21 -05:00
}
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
static void
expected_fail_marshal(int expected_error, const char *format, ...)
{
struct wl_closure *closure;
static const uint32_t opcode = 4444;
remove trailing whitespaces Remove trailing whitespaces because they are not needed and jumping to the end of al ine should do just that and not jump to the whitespace.
2015-05-15 17:12:41 +02:00
static const struct wl_interface test_interface = {
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
.name = "test_object"
};
static struct wl_object sender = { 0 };
struct wl_message message = { "test", format, NULL };
sender.interface = &test_interface;
sender.id = 1234;
va_list ap;
va_start(ap, format);
closure = wl_closure_vmarshal(&sender, opcode, ap, &message);
va_end(ap);
assert(closure == NULL);
assert(errno == expected_error);
}
connection: Dynamically resize connection buffers When using fixed size connection buffers, if either the client or the server is sending requests faster than the other end can cope with, the connection buffers will fill up, eventually killing the connection. This can be a problem for example with Xwayland mapping a lot of windows, faster than the Wayland compositor can cope with, or a high-rate mouse flooding the Wayland client with pointer events. To avoid the issue, resize the connection buffers dynamically when they get full. Both data and fd buffers are resized on demand. The default max buffer size is controlled via the wl_display interface while each client's connection buffer size is adjustable for finer control. The purpose is to explicitly have larger connection buffers for specific clients such as Xwayland, or set a larger buffer size for the client with pointer focus to deal with a higher input events rate. v0: Manuel: Dynamically resize connection buffers - Both data and fd buffers are resized on demand. v1: Olivier 1. Add support for unbounded buffers on the client side and growable (yet limited) connection buffers on the server side. 2. Add the API to set the default maximum size and a limit for a given client. 3. Add tests for growable connection buffers and adjustable limits. v2: Additional fixes by John: 1. Fix the size calculation in ring_buffer_check_space() 2. Fix wl_connection_read() to return gracefully once it has read up to the max buffer size, rather than returning an error. 3. If wl_connection_flush() fails with EAGAIN but the transmit ring-buffer has space remaining (or can be expanded), wl_connection_queue() should store the message rather than returning an error. 4. When the receive ring-buffer is at capacity but more data is available to be read, wl_connection_read() should attempt to expand the ring-buffer in order to read the remaining data. v3: Thomas Lukaszewicz <tluk@chromium.org> Add a test for unbounded buffers v4: Add a client API as well to force bounded buffers (unbounded by default (Olivier) v5: Simplify ring_buffer_ensure_space() (Sebastian) Co-authored-by: Olivier Fourdan <ofourdan@redhat.com> Co-authored-by: John Lindgren <john@jlindgren.net> Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by: Manuel Stoeckl <code@mstoeckl.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: John Lindgren <john@jlindgren.net> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net> Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
2021-09-25 22:34:44 -04:00
static void
marshal_send(struct marshal_data *data, const char *format, ...)
{
struct wl_closure *closure;
static const uint32_t opcode = 4444;
static struct wl_object sender = { NULL, NULL, 1234 };
struct wl_message message = { "test", format, NULL };
va_list ap;
va_start(ap, format);
closure = wl_closure_vmarshal(&sender, opcode, ap, &message);
va_end(ap);
assert(closure);
assert(wl_closure_send(closure, data->write_connection) == 0);
wl_closure_destroy(closure);
}
connection: Don't write past the end of the connection buffer If a message was too big to fit in the connection buffer, the code in wl_buffer_put would just write past the end of it. I haven't seen any real world use case that would trigger this bug, but it was possible to trigger it by sending a long enough string to the wl_data_source.offer request. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69267
2014-04-17 18:20:37 +03:00
static void
expected_fail_marshal_send(struct marshal_data *data, int expected_error,
const char *format, ...)
{
struct wl_closure *closure;
static const uint32_t opcode = 4444;
static struct wl_object sender = { NULL, NULL, 1234 };
struct wl_message message = { "test", format, NULL };
va_list ap;
va_start(ap, format);
closure = wl_closure_vmarshal(&sender, opcode, ap, &message);
va_end(ap);
assert(closure);
assert(wl_closure_send(closure, data->write_connection) < 0);
assert(errno == expected_error);
wl_closure_destroy(closure);
}
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
TEST(connection_marshal_nullables)
{
struct marshal_data data;
struct wl_object object;
const char text[] = "curry";
setup_marshal_data(&data);
expected_fail_marshal(EINVAL, "o", NULL);
expected_fail_marshal(EINVAL, "s", NULL);
expected_fail_marshal(EINVAL, "a", NULL);
marshal(&data, "?o", 12, NULL);
assert(data.buffer[2] == 0);
marshal(&data, "?s", 12, NULL);
assert(data.buffer[2] == 0);
object.id = 55293;
marshal(&data, "?o", 12, &object);
assert(data.buffer[2] == object.id);
marshal(&data, "?s", 20, text);
assert(data.buffer[2] == sizeof text);
assert(strcmp((char *) &data.buffer[3], text) == 0);
release_marshal_data(&data);
}
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
static void
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
validate_demarshal_u(struct marshal_data *data,
struct wl_object *object, uint32_t u)
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
{
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
assert(data->value.u == u);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
}
static void
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
validate_demarshal_i(struct marshal_data *data,
struct wl_object *object, int32_t i)
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
{
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
assert(data->value.i == i);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
}
static void
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
validate_demarshal_s(struct marshal_data *data,
struct wl_object *object, const char *s)
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
{
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
if (data->value.s != NULL)
assert(strcmp(data->value.s, s) == 0);
else
assert(s == NULL);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
}
connection-test: Test fd transport
2012-03-24 14:27:30 -04:00
static void
validate_demarshal_h(struct marshal_data *data,
struct wl_object *object, int fd)
{
struct stat buf1, buf2;
assert(fd != data->value.h);
fstat(fd, &buf1);
fstat(data->value.h, &buf2);
assert(buf1.st_dev == buf2.st_dev);
assert(buf1.st_ino == buf2.st_ino);
close(fd);
close(data->value.h);
}
Add support for signed 24.8 decimal numbers 'fixed' is a signed decimal type which offers a sign bit, 23 bits of integer precision, and 8 bits of decimal precision. This is exposed as an opaque struct with conversion helpers to and from double and int on the C API side. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-05-08 17:17:25 +01:00
static void
validate_demarshal_f(struct marshal_data *data,
struct wl_object *object, wl_fixed_t f)
{
assert(data->value.i == f);
}
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
static void
demarshal(struct marshal_data *data, const char *format,
uint32_t *msg, void (*func)(void))
{
struct wl_message message = { "test", format, NULL };
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
struct wl_closure *closure;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
struct wl_map objects;
Change wl_closure_invoke to take an opcode instead of an actual function pointer Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
2013-03-08 22:26:12 -06:00
struct wl_object object = { NULL, &func, 0 };
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
int size = msg[1] >> 16;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
assert(write(data->s[1], msg, size) == size);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_read(data->read_connection) == size);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
Update tests for wl_map changes and add a map_flags test
2013-06-05 09:52:39 -05:00
wl_map_init(&objects, WL_MAP_SERVER_SIDE);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
object.id = msg[0];
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
closure = wl_connection_demarshal(data->read_connection,
size, &objects, &message);
assert(closure);
Change wl_closure_invoke to take an opcode instead of an actual function pointer Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
2013-03-08 22:26:12 -06:00
wl_closure_invoke(closure, WL_CLOSURE_INVOKE_SERVER, &object, 0, data);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
wl_closure_destroy(closure);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
}
TEST(connection_demarshal)
{
struct marshal_data data;
uint32_t msg[10];
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
setup_marshal_data(&data);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
data.value.u = 8000;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
msg[0] = 400200; /* object id */
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
msg[1] = 12 << 16; /* size = 12, opcode = 0 */
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
msg[2] = data.value.u;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
demarshal(&data, "u", msg, (void *) validate_demarshal_u);
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
data.value.i = -557799;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
msg[0] = 400200;
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
msg[1] = 12 << 16;
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
msg[2] = data.value.i;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
demarshal(&data, "i", msg, (void *) validate_demarshal_i);
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
data.value.s = "superdude";
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
msg[0] = 400200;
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
msg[1] = 24 << 16;
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
msg[2] = 10;
connection-test: Pad out strings with null bytes The connection_demarshal test writes a 10 byte string into a wayland message, but doesn't pad it out to a four byte boundary. This leads to the last 32-bit word of the message being partially uninitialized, which triggers an msan violation when the message is written to the socket. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-07-10 00:09:59 +10:00
msg[3 + msg[2]/4] = 0;
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
memcpy(&msg[3], data.value.s, msg[2]);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
demarshal(&data, "s", msg, (void *) validate_demarshal_s);
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
data.value.s = "superdude";
msg[0] = 400200;
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
msg[1] = 24 << 16;
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
msg[2] = 10;
connection-test: Pad out strings with null bytes The connection_demarshal test writes a 10 byte string into a wayland message, but doesn't pad it out to a four byte boundary. This leads to the last 32-bit word of the message being partially uninitialized, which triggers an msan violation when the message is written to the socket. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-07-10 00:09:59 +10:00
msg[3 + msg[2]/4] = 0;
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
memcpy(&msg[3], data.value.s, msg[2]);
demarshal(&data, "?s", msg, (void *) validate_demarshal_s);
Add support for signed 24.8 decimal numbers 'fixed' is a signed decimal type which offers a sign bit, 23 bits of integer precision, and 8 bits of decimal precision. This is exposed as an opaque struct with conversion helpers to and from double and int on the C API side. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-05-08 17:17:25 +01:00
data.value.i = wl_fixed_from_double(-90000.2390);
msg[0] = 400200;
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
msg[1] = 12 << 16;
Add support for signed 24.8 decimal numbers 'fixed' is a signed decimal type which offers a sign bit, 23 bits of integer precision, and 8 bits of decimal precision. This is exposed as an opaque struct with conversion helpers to and from double and int on the C API side. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-05-08 17:17:25 +01:00
msg[2] = data.value.i;
demarshal(&data, "f", msg, (void *) validate_demarshal_f);
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
data.value.s = NULL;
msg[0] = 400200;
connection-test: Encode size in message headers correctly In these tests, message sizes are inconsistently encoded in either the upper or lower 16 bits of the second word of the message. Resolve this in favour of using the upper 16 bits, as this is how messages are supposed to be encoded, even though that aspect of message decoding isn't being tested here. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 20:05:47 +10:00
msg[1] = 12 << 16;
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
msg[2] = 0;
remove trailing whitespaces Remove trailing whitespaces because they are not needed and jumping to the end of al ine should do just that and not jump to the whitespace.
2015-05-15 17:12:41 +02:00
demarshal(&data, "?s", msg, (void *) validate_demarshal_s);
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
tests: Use different connections for read and write tests The connection tests so far only use one connection at a time, but this prepares for tests that use a connection on both sides of the socket.
2012-03-23 11:32:17 -04:00
release_marshal_data(&data);
tests: Add demarshal tests
2012-03-05 22:26:17 -05:00
}
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
static void
remove trailing whitespaces Remove trailing whitespaces because they are not needed and jumping to the end of al ine should do just that and not jump to the whitespace.
2015-05-15 17:12:41 +02:00
marshal_demarshal(struct marshal_data *data,
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
void (*func)(void), int size, const char *format, ...)
{
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
struct wl_closure *closure;
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
static const int opcode = 4444;
static struct wl_object sender = { NULL, NULL, 1234 };
struct wl_message message = { "test", format, NULL };
struct wl_map objects;
Change wl_closure_invoke to take an opcode instead of an actual function pointer Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
2013-03-08 22:26:12 -06:00
struct wl_object object = { NULL, &func, 0 };
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
va_list ap;
uint32_t msg[1] = { 1234 };
va_start(ap, format);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
closure = wl_closure_vmarshal(&sender, opcode, ap, &message);
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
va_end(ap);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
assert(closure);
assert(wl_closure_send(closure, data->write_connection) == 0);
wl_closure_destroy(closure);
Change filedescriptor API to be thread safe The update callback for the file descriptors was always a bit awkward and un-intuitive. The idea was that whenever the protocol code needed to write data to the fd it would call the 'update' function. This function would adjust the mainloop so that it polls for POLLOUT on the fd so we can eventually flush the data to the socket. The problem is that in multi-threaded applications, any thread can issue a request, which writes data to the output buffer and thus triggers the update callback. Thus, we'll be calling out with the display mutex held and may call from any thread. The solution is to eliminate the udpate callback and just require that the application or server flushes all connection buffers before blocking. This turns out to be a simpler API, although we now require clients to deal with EAGAIN and non-blocking writes. It also saves a few syscalls, since the socket will be writable most of the time and most writes will complete, so we avoid changing epoll to poll for POLLOUT, then write and then change it back for each write.
2012-10-04 16:54:22 -04:00
assert(wl_connection_flush(data->write_connection) == size);
assert(wl_connection_read(data->read_connection) == size);
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
Update tests for wl_map changes and add a map_flags test
2013-06-05 09:52:39 -05:00
wl_map_init(&objects, WL_MAP_SERVER_SIDE);
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
object.id = msg[0];
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
closure = wl_connection_demarshal(data->read_connection,
size, &objects, &message);
connection-test: assert closure is not NULL before invoking it Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
2014-01-10 12:28:43 -08:00
assert(closure);
Change wl_closure_invoke to take an opcode instead of an actual function pointer Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
2013-03-08 22:26:12 -06:00
wl_closure_invoke(closure, WL_CLOSURE_INVOKE_SERVER, &object, 0, data);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
wl_closure_destroy(closure);
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
}
TEST(connection_marshal_demarshal)
{
struct marshal_data data;
tests: rename temporary files This is libwayland, not weston, so call the temporary files wayland-tests-*, not weston-tests-*. This is a candidate for the stable branch. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2012-12-03 16:58:25 +02:00
char f[] = "/tmp/wayland-tests-XXXXXX";
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
setup_marshal_data(&data);
connection-test: Add more test cases
2012-03-23 16:57:34 -04:00
data.value.u = 889911;
marshal_demarshal(&data, (void *) validate_demarshal_u,
12, "u", data.value.u);
data.value.i = -13;
marshal_demarshal(&data, (void *) validate_demarshal_i,
12, "i", data.value.i);
connection-test: Store expected result in struct marshal_data
2012-03-23 16:56:19 -04:00
data.value.s = "cookie robots";
marshal_demarshal(&data, (void *) validate_demarshal_s,
28, "s", data.value.s);
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
protocol: Add explicit nullable types Most of the time it does not make sense to pass a NULL object, string, or array to a protocol request. This commit adds an explicit “allow-null” attribute to mark the request arguments where NULL makes sense. Passing a NULL object, string, or array to a protocol request which is not marked as allow-null is now an error. An implementation will never receive a NULL value for these arguments from a client. Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
2012-07-02 20:03:30 +10:00
data.value.s = "cookie robots";
marshal_demarshal(&data, (void *) validate_demarshal_s,
28, "?s", data.value.s);
connection-test: Test fd transport
2012-03-24 14:27:30 -04:00
data.value.h = mkstemp(f);
assert(data.value.h >= 0);
tests: Don't leave temporary files behind Signed-off-by: Sven Joachim <svenjoac@gmx.de>
2012-12-02 22:42:11 +01:00
unlink(f);
connection-test: Test fd transport
2012-03-24 14:27:30 -04:00
marshal_demarshal(&data, (void *) validate_demarshal_h,
8, "h", data.value.h);
Add support for signed 24.8 decimal numbers 'fixed' is a signed decimal type which offers a sign bit, 23 bits of integer precision, and 8 bits of decimal precision. This is exposed as an opaque struct with conversion helpers to and from double and int on the C API side. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-05-08 17:17:25 +01:00
data.value.i = wl_fixed_from_double(1234.5678);
marshal_demarshal(&data, (void *) validate_demarshal_f,
12, "f", data.value.i);
data.value.i = wl_fixed_from_double(-90000.2390);
marshal_demarshal(&data, (void *) validate_demarshal_f,
12, "f", data.value.i);
data.value.i = wl_fixed_from_double((1 << 23) - 1 + 0.0941);
marshal_demarshal(&data, (void *) validate_demarshal_f,
12, "f", data.value.i);
tests: Add marshal+demarshal connection test
2012-03-23 11:41:34 -04:00
release_marshal_data(&data);
}
connection-test: Add test case to stress connection buffers This catches the bug fixed in cab70c9e5d8c38260a07bb1ddb7618826a120465.
2012-03-24 14:34:05 -04:00
tests: Demarshalling of very long array/string lengths. Attempting to demarshal message with array or string longer than its body should return failure. Handling the length correctly is tricky when it gets to near-UINT32_MAX values. Unexpected overflows can cause crashes and other security issues. These tests verify that demarshalling such message gives failure instead of crash. v2: Added consts, serialized opcode and size properly, updated style. Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Acked-by: Derek Foreman <derek.foreman.samsung@gmail.com>
2018-08-21 10:47:29 +02:00
static void
expected_fail_demarshal(struct marshal_data *data, const char *format,
const uint32_t *msg, int expected_error)
{
struct wl_message message = { "test", format, NULL };
struct wl_closure *closure;
struct wl_map objects;
int size = (msg[1] >> 16);
assert(write(data->s[1], msg, size) == size);
assert(wl_connection_read(data->read_connection) == size);
wl_map_init(&objects, WL_MAP_SERVER_SIDE);
closure = wl_connection_demarshal(data->read_connection,
size, &objects, &message);
assert(closure == NULL);
assert(errno == expected_error);
}
connection: Handle non-nullable strings in wl_connection_demarshal Currently a null string passed into a non-nullable argument of a message will decode succesfully, probably resulting in the handler function crashing. Instead treat it the same way we do non-nullable objects and ids. Signed-off-by: Fergus Dall <sidereal@google.com>
2021-06-22 19:31:26 +10:00
TEST(connection_demarshal_null_strings)
{
struct marshal_data data;
uint32_t msg[3];
setup_marshal_data(&data);
data.value.s = NULL;
msg[0] = 400200; /* object id */
msg[1] = 12 << 16; /* size = 12, opcode = 0 */
msg[2] = 0; /* string length = 0 */
demarshal(&data, "?s", msg, (void *) validate_demarshal_s);
expected_fail_demarshal(&data, "s", msg, EINVAL);
release_marshal_data(&data);
}
tests: fix typos
2020-12-17 15:40:04 -05:00
/* These tests are verifying that the demarshaling code will gracefully handle
tests: Demarshalling of very long array/string lengths. Attempting to demarshal message with array or string longer than its body should return failure. Handling the length correctly is tricky when it gets to near-UINT32_MAX values. Unexpected overflows can cause crashes and other security issues. These tests verify that demarshalling such message gives failure instead of crash. v2: Added consts, serialized opcode and size properly, updated style. Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Acked-by: Derek Foreman <derek.foreman.samsung@gmail.com>
2018-08-21 10:47:29 +02:00
* clients lying about string and array lengths and giving values near
* UINT32_MAX. Before fixes f7fdface and f5b9e3b9 this test would crash on
* 32bit systems.
*/
TEST(connection_demarshal_failures)
{
struct marshal_data data;
unsigned int i;
uint32_t msg[3];
const uint32_t overflowing_values[] = {
/* Values very close to UINT32_MAX. Before f5b9e3b9 these
* would cause integer overflow in DIV_ROUNDUP. */
0xffffffff, 0xfffffffe, 0xfffffffd, 0xfffffffc,
/* Values at various offsets from UINT32_MAX. Before f7fdface
* these would overflow the "p" pointer on 32bit systems,
* effectively subtracting the offset from it. It had good
* chance to cause crash depending on what was stored at that
* offset before "p". */
0xfffff000, 0xffffd000, 0xffffc000, 0xffffb000
};
setup_marshal_data(&data);
/* sender_id, does not matter */
msg[0] = 0;
/* (size << 16 | opcode), opcode is 0, does not matter */
msg[1] = sizeof(msg) << 16;
for (i = 0; i < ARRAY_LENGTH(overflowing_values); i++) {
/* length of the string or array */
msg[2] = overflowing_values[i];
expected_fail_demarshal(&data, "s", msg, EINVAL);
expected_fail_demarshal(&data, "a", msg, EINVAL);
}
release_marshal_data(&data);
}
connection-test: Add test case to stress connection buffers This catches the bug fixed in cab70c9e5d8c38260a07bb1ddb7618826a120465.
2012-03-24 14:34:05 -04:00
TEST(connection_marshal_alot)
{
struct marshal_data data;
char f[64];
int i;
setup_marshal_data(&data);
remove trailing whitespaces Remove trailing whitespaces because they are not needed and jumping to the end of al ine should do just that and not jump to the whitespace.
2015-05-15 17:12:41 +02:00
connection-test: Add test case to stress connection buffers This catches the bug fixed in cab70c9e5d8c38260a07bb1ddb7618826a120465.
2012-03-24 14:34:05 -04:00
/* We iterate enough to make sure we wrap the circular buffers
* for both regular data an fds. */
for (i = 0; i < 2000; i++) {
tests: rename temporary files This is libwayland, not weston, so call the temporary files wayland-tests-*, not weston-tests-*. This is a candidate for the stable branch. Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2012-12-03 16:58:25 +02:00
strcpy(f, "/tmp/wayland-tests-XXXXXX");
connection-test: Add test case to stress connection buffers This catches the bug fixed in cab70c9e5d8c38260a07bb1ddb7618826a120465.
2012-03-24 14:34:05 -04:00
data.value.h = mkstemp(f);
assert(data.value.h >= 0);
tests: Don't leave temporary files behind Signed-off-by: Sven Joachim <svenjoac@gmx.de>
2012-12-02 22:42:11 +01:00
unlink(f);
connection-test: Add test case to stress connection buffers This catches the bug fixed in cab70c9e5d8c38260a07bb1ddb7618826a120465.
2012-03-24 14:34:05 -04:00
marshal_demarshal(&data, (void *) validate_demarshal_h,
8, "h", data.value.h);
}
release_marshal_data(&data);
}
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
connection: Don't write past the end of the connection buffer If a message was too big to fit in the connection buffer, the code in wl_buffer_put would just write past the end of it. I haven't seen any real world use case that would trigger this bug, but it was possible to trigger it by sending a long enough string to the wl_data_source.offer request. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69267
2014-04-17 18:20:37 +03:00
TEST(connection_marshal_too_big)
{
struct marshal_data data;
char *big_string = malloc(5000);
connection-test: check malloc result Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
2014-05-05 14:45:20 -07:00
assert(big_string);
connection: Don't write past the end of the connection buffer If a message was too big to fit in the connection buffer, the code in wl_buffer_put would just write past the end of it. I haven't seen any real world use case that would trigger this bug, but it was possible to trigger it by sending a long enough string to the wl_data_source.offer request. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69267
2014-04-17 18:20:37 +03:00
memset(big_string, ' ', 4999);
big_string[4999] = '\0';
setup_marshal_data(&data);
expected_fail_marshal_send(&data, E2BIG, "s", big_string);
release_marshal_data(&data);
free(big_string);
}
connection: Dynamically resize connection buffers When using fixed size connection buffers, if either the client or the server is sending requests faster than the other end can cope with, the connection buffers will fill up, eventually killing the connection. This can be a problem for example with Xwayland mapping a lot of windows, faster than the Wayland compositor can cope with, or a high-rate mouse flooding the Wayland client with pointer events. To avoid the issue, resize the connection buffers dynamically when they get full. Both data and fd buffers are resized on demand. The default max buffer size is controlled via the wl_display interface while each client's connection buffer size is adjustable for finer control. The purpose is to explicitly have larger connection buffers for specific clients such as Xwayland, or set a larger buffer size for the client with pointer focus to deal with a higher input events rate. v0: Manuel: Dynamically resize connection buffers - Both data and fd buffers are resized on demand. v1: Olivier 1. Add support for unbounded buffers on the client side and growable (yet limited) connection buffers on the server side. 2. Add the API to set the default maximum size and a limit for a given client. 3. Add tests for growable connection buffers and adjustable limits. v2: Additional fixes by John: 1. Fix the size calculation in ring_buffer_check_space() 2. Fix wl_connection_read() to return gracefully once it has read up to the max buffer size, rather than returning an error. 3. If wl_connection_flush() fails with EAGAIN but the transmit ring-buffer has space remaining (or can be expanded), wl_connection_queue() should store the message rather than returning an error. 4. When the receive ring-buffer is at capacity but more data is available to be read, wl_connection_read() should attempt to expand the ring-buffer in order to read the remaining data. v3: Thomas Lukaszewicz <tluk@chromium.org> Add a test for unbounded buffers v4: Add a client API as well to force bounded buffers (unbounded by default (Olivier) v5: Simplify ring_buffer_ensure_space() (Sebastian) Co-authored-by: Olivier Fourdan <ofourdan@redhat.com> Co-authored-by: John Lindgren <john@jlindgren.net> Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by: Manuel Stoeckl <code@mstoeckl.com> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: John Lindgren <john@jlindgren.net> Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net> Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
2021-09-25 22:34:44 -04:00
TEST(connection_marshal_big_enough)
{
struct marshal_data data;
char *big_string = malloc(5000);
assert(big_string);
memset(big_string, ' ', 4999);
big_string[4999] = '\0';
setup_marshal_data(&data);
wl_connection_set_max_buffer_size(data.write_connection, 5120);
marshal_send(&data, "s", big_string);
release_marshal_data(&data);
free(big_string);
}
TEST(connection_marshal_unbounded_boundary_size)
{
/* A string of lenth 8178 requires a buffer size of exactly 2^13. */
struct marshal_data data;
char *big_string = malloc(8178);
assert(big_string);
memset(big_string, ' ', 8177);
big_string[8177] = '\0';
setup_marshal_data(&data);
/* Set the max size to 0 (unbounded). */
wl_connection_set_max_buffer_size(data.write_connection, 0);
marshal_send(&data, "s", big_string);
release_marshal_data(&data);
free(big_string);
}
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
static void
marshal_helper(const char *format, void *handler, ...)
{
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
struct wl_closure *closure;
Change wl_closure_invoke to take an opcode instead of an actual function pointer Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
2013-03-08 22:26:12 -06:00
static struct wl_object sender = { NULL, NULL, 1234 };
struct wl_object object = { NULL, &handler, 0 };
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
static const int opcode = 4444;
struct wl_message message = { "test", format, NULL };
va_list ap;
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
int done;
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
va_start(ap, handler);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
closure = wl_closure_vmarshal(&sender, opcode, ap, &message);
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
va_end(ap);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
assert(closure);
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
done = 0;
Change wl_closure_invoke to take an opcode instead of an actual function pointer Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
2013-03-08 22:26:12 -06:00
wl_closure_invoke(closure, WL_CLOSURE_INVOKE_SERVER, &object, 0, &done);
tests: Update test cases to new closure allocate convention
2012-06-15 16:09:39 -04:00
wl_closure_destroy(closure);
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
assert(done);
}
static void
suu_handler(void *data, struct wl_object *object,
const char *s, uint32_t u1, uint32_t u2)
{
int *done = data;
assert(strcmp(s, "foo") == 0);
connection-test: fix assert Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2017-03-16 11:46:06 +00:00
assert(u1 == 500);
assert(u2 == 404040);
tests: Test invoking closures built with wl_closure_vmarshal()
2012-04-22 14:17:02 -04:00
*done = 1;
}
TEST(invoke_closure)
{
marshal_helper("suu", suu_handler, "foo", 500, 404040);
}
connection-test: add tests for closure leaks When we destroy closure, we are leaking memory sometimes. Signed-off-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2014-12-19 14:53:03 +01:00
static void
leak_closure(void)
{
struct wl_callback *cb;
struct pollfd pfd;
struct client *c = client_connect();
cb = wl_display_sync(c->wl_display);
assert(cb);
assert(wl_display_flush(c->wl_display) > 0);
/* we don't need it, it is referenced */
wl_callback_destroy(cb);
pfd.fd = wl_display_get_fd(c->wl_display);
pfd.events = POLLIN;
test_set_timeout(2);
assert(poll(&pfd, 1, -1) == 1);
/* read events, but do not dispatch them */
assert(wl_display_prepare_read(c->wl_display) == 0);
assert(wl_display_read_events(c->wl_display) == 0);
/*
* now we have wl_callback.done and wl_display.delete_id queued;
* if we now release the queue (in wl_display_disconnect())
* we should not leak memory
*/
client_disconnect(c);
}
TEST(closure_leaks)
{
struct display *d = display_create();
tests: Pass argument to client main Change the API to pass an "void *" argument to the client main function, allowing the caller to call the same main function with different input. A helper (client_create_noarg) is added for when no argument is passed, and the existing test cases are changed to use this function instead. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2015-12-28 11:25:00 +08:00
client_create_noarg(d, leak_closure);
connection-test: add tests for closure leaks When we destroy closure, we are leaking memory sometimes. Signed-off-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2014-12-19 14:53:03 +01:00
display_run(d);
display_destroy(d);
}
static void
leak_after_error(void)
{
struct client *c = client_connect();
/* this should return -1, because we'll send error
* from server. */
assert(stop_display(c, 1) == -1);
assert(wl_display_dispatch_pending(c->wl_display) == -1);
assert(wl_display_get_error(c->wl_display) == ENOMEM);
/* after we got error, we have display_resume event
* in the queue. It should be freed in wl_display_disconnect().
* Let's see! */
wl_proxy_destroy((struct wl_proxy *) c->tc);
wl_display_disconnect(c->wl_display);
free(c);
}
TEST(closure_leaks_after_error)
{
struct display *d = display_create();
struct client_info *cl;
tests: Pass argument to client main Change the API to pass an "void *" argument to the client main function, allowing the caller to call the same main function with different input. A helper (client_create_noarg) is added for when no argument is passed, and the existing test cases are changed to use this function instead. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2015-12-28 11:25:00 +08:00
cl = client_create_noarg(d, leak_after_error);
connection-test: add tests for closure leaks When we destroy closure, we are leaking memory sometimes. Signed-off-by: Marek Chalupa <mchqwerty@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2014-12-19 14:53:03 +01:00
display_run(d);
wl_client_post_no_memory(cl->wl_client);
display_resume(d);
display_destroy(d);
}
tests: add request_bogus_size This attempts to reproduce the error conditions from https://gitlab.freedesktop.org/wayland/wayland/issues/52 and make it crash. While the crash was repeatable in my tests, it depends on garbage on stack leading to access of invalid memory, which is not guaranteed. This is a FAIL_TEST, so that the following fix commit can be verified. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr>
2019-03-04 13:45:58 +02:00
/** Raw read from socket expecting wl_display.error
*
* \param sockfd The socket to read from.
* \param expected_error The expected wl_display error code.
*
* Reads the socket and manually parses one message, expecting it to be a
* wl_display.error with the wl_display as the originating object.
* Asserts that the received error code is expected_error.
*/
static void
expect_error_recv(int sockfd, uint32_t expected_error)
{
uint32_t buf[1024];
ssize_t slen;
uint32_t opcode;
int str_len;
slen = recv(sockfd, buf, sizeof buf, 0);
assert(slen >= 2 * (ssize_t)sizeof (uint32_t));
opcode = buf[1] & 0xffff;
fprintf(stderr, "Received %zd bytes, object %u, opcode %u\n",
slen, buf[0], opcode);
/* check error event */
assert(buf[0] == 1);
assert(opcode == WL_DISPLAY_ERROR);
str_len = buf[4];
assert(str_len > 0);
assert(str_len <= slen - 5 * (ssize_t)sizeof (uint32_t));
fprintf(stderr, "Error event on object %u, code %u, message \"%*s\"\n",
buf[2], buf[3], str_len, (const char *)&buf[5]);
assert(buf[3] == expected_error);
}
/* A test for https://gitlab.freedesktop.org/wayland/wayland/issues/52
* trying to provoke a read from uninitialized memory in
* wl_connection_demarshal() for sender_id and opcode.
*
* This test might not fail as is even with #52 unfixed, since there is no way
* to detect what happens and the crash with zero size depends on stack content.
* However, running under Valgrind would point out invalid reads and use of
* uninitialized values.
*/
connection: fix demarshal of invalid header The size argument to wl_connection_demarshal() is taken from the message by the caller wl_client_connection_data(), therefore 'size' is untrusted data controllable by a Wayland client. The size should always be at least the header size, otherwise the header is invalid. If the size is smaller than header size, it leads to reading past the end of allocated memory. Furthermore if size is zero, wl_closure_init() changes behaviour and leaves num_arrays uninitialized, leading to access of arbitrary memory. Check that 'size' fits at least the header. The space for arguments is already properly checked. This makes the request_bogus_size test free of errors under Valgrind. Fixes: https://gitlab.freedesktop.org/wayland/wayland/issues/52 Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr>
2019-03-06 13:42:23 +02:00
TEST(request_bogus_size)
tests: add request_bogus_size This attempts to reproduce the error conditions from https://gitlab.freedesktop.org/wayland/wayland/issues/52 and make it crash. While the crash was repeatable in my tests, it depends on garbage on stack leading to access of invalid memory, which is not guaranteed. This is a FAIL_TEST, so that the following fix commit can be verified. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr>
2019-03-04 13:45:58 +02:00
{
struct wl_display *display;
struct wl_client *client;
int s[2];
uint32_t msg[3];
int bogus_size;
test_set_timeout(1);
/*
* The manufactured message has real size 12. Test all bogus sizes
* smaller than that, and zero as the last one since wl_closure_init
* handles zero specially and having garbage in the stack makes it more
* likely to crash in wl_connection_demarshal.
*/
for (bogus_size = 11; bogus_size >= 0; bogus_size--) {
fprintf(stderr, "* bogus size %d\n", bogus_size);
assert(socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, s) == 0);
display = wl_display_create();
assert(display);
client = wl_client_create(display, s[0]);
assert(client);
/* manufacture a request that lies about its size */
msg[0] = 1; /* sender id: wl_display */
msg[1] = (bogus_size << 16) | WL_DISPLAY_SYNC; /* size and opcode */
msg[2] = 2; /* sync argument: new_id for wl_callback */
assert(send(s[1], msg, sizeof msg, 0) == sizeof msg);
wl_event_loop_dispatch(wl_display_get_event_loop(display), 0);
expect_error_recv(s[1], WL_DISPLAY_ERROR_INVALID_METHOD);
/* Do not wl_client_destroy, the error already caused it. */
close(s[1]);
wl_display_destroy(display);
}
}
Reference in a new issue Copy permalink