When parsing a line of "key3=foo\i\" in a keyfile,
g_key_file_parse_value_as_string currently first sets the error to
'contains invalid escape' and later to 'contains escape character at end
of line'.
This leaks the first GError and causes the following warning message:
Error set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is
NULL before it's set. The overwriting error message was: Key file
contains escape character at end of line
Fix this by returning when an error is detected. As we may have
collected data in pieces, we instead collect to a tmp_pieces GSList and
free it on error.
The fields are fully validated in `validate_headers()` in
`gdbusmessage.c` now, so the connection code should be able to rely on
the required ones being non-`NULL`.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3061
`object_path` and `path` were doing exactly the same thing here.
This introduces no functional changes.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
We already validated that the required headers for each type of D-Bus
message were present. However, we didn’t validate that they contained a
variant of the right type. This could lead to functions like
`g_dbus_message_get_path()` returning `NULL` unexpectedly.
This failure could only be hit when using GDBus in peer-to-peer mode, or
with a D-Bus server which didn’t validate the headers itself. The
reference D-Bus server does validate the headers, and doesn’t forward
invalid messages to clients.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3061
This patch is based upon Garrett Regier's work from 2015 to provide
some reliability and predictability to how disposal handles weak
reference state.
A primary problem is that GWeakRef and GWeakNotify state is shared and
therefore you cannot rely on GWeakRef status due to a GWeakNotify
calling into second-degree code.
It's important to ensure that both weak pointer locations and GWeakRef
will do the proper thing before user callbacks are executed during
disposal. Otherwise, user callbacks cannot rely on the status of their
weak pointers. That would be mostly okay but becomes an issue when
second degree objects are then disposed before any notification of
dependent object disposal.
Consider objects A and B.
`A` contains a reference to `B` and `B` contains a `GWeakRef` to `A`.
When `A` is disposed, `B` may be disposed as a consequence but has not
yet been notified that `A` has been disposed. It's `GWeakRef` may also
cause liveness issues if `GWeakNotify` on `A` result in tertiary code
running which wants to interact with `B`.
This example is analagous to how `GtkTextView` and `GtkTextBuffer` work
in text editing applications.
To provide application and libraries the ability to handle this using
already existing API, `GWeakRef` is separated into it's own GData quark
so that weak locations and `GWeakRef` are cleared before user code is
executed as a consequence of `GData` cleanup.
# Conflicts:
# gobject/tests/signals.c
On 32 bit systems 'long' value will overflow in 2038 and become negative.
As it is used to index into letters array, and % operation preserves signs,
data corruption will then occur.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
The point of to be able to call localtime()/localtime_r() from another
place inside glib (without reimplementing the #ifdef).
- also handles failures from localtime_r(). It is documented that it
might fail, so detect the failure.
- in case of failures of localtime(), still initialize the GDate.
Previously, we may error out with a g_critical() assertion before.
However, now that failures from localtime_r() are also caught, I think
we should make an effort to initialize the GDate to something. It
either way it not supposed to happen.
For completeness. There probably won't be any, but the XDG base directory
specification is most useful if it's consistently followed everywhere,
and the specification says to look in XDG_DATA_HOME before XDG_DATA_DIRS.
Signed-off-by: Simon McVittie <smcv@debian.org>
The Python code historically always searched DATADIR/gir-1.0 (always)
and /usr/share/gir-1.0 (only on Unix); since the previous commit, they
are searched after the GIR_DIR. Do the same here, to make the C and
Python search paths match up.
With the default gir_dir_prefix, searching both GIR_DIR and
DATADIR/gir-1.0 is redundant. However, if gir_dir_prefix is changed to
something else, for example -Dgir_dir_prefix=lib64, always searching
DATADIR/gir-1.0 provides backwards compatibility with pre-existing GIR
that might already be stored in DATADIR/gir-1.0.
Resolves: #455 (in conjunction with previous commit)
Helps: #323
Signed-off-by: Simon McVittie <smcv@debian.org>
This is searched after any command-line includes paths, but before the
XDG_DATA_DIRS or any built-in paths. For example, if
libraries are installed in /opt/gnome and GObject-Introspection was
configured with -Dgir_dir_prefix=lib64, you could set either
GI_GIR_PATH=/opt/gnome/lib64/gir-1.0 or
XDG_DATA_DIRS=/opt/gnome/lib64:/opt/gnome/share:${XDG_DATA_DIRS}.
Use this to communicate the ../gir directory to giscanner instead
of modifying Python's builtins.
Helps: #323, #455
Signed-off-by: Simon McVittie <smcv@debian.org>
Print the PID, the errno and the pidfd in case of an unexpected failure
in g_child_watch_dispatch().
This is always(?) caused by a bug in the user application. Also hint to
g_child_watch_source_new() documentation for possible causes.
Also use G_PID_FORMAT for printing GPid values.
Prompted by #3071, this clarifies that `g_test_trap_subprocess()` uses
`g_child_watch_source_new()` internally, so it will not work if any of
the preconditions for using that API are not met. In particular, if
`SIGCHLD` is ignored, things will break.
This documentation is not meant to be an API guarantee which constrains
the implementation of `g_test_trap_subprocess()` in future, just a tip
to people currently using the API.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3071
This is one step towards rectifying the mistake of using `FD_CLOEXEC` in
the first place. Eventually we may deprecate support for `FD_CLOEXEC`,
as the `O_*` flags better match the underlying `pipe()` API.
See discussion on
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3459#note_1779264
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
