g_win32_package_parser_enum_packages() reads beyond the end of a buffer
when doing a memcpy. With app verifier enabled on Windows, it causes
the application to crash on startup.
This change limits the memcpy to the size of the source string.
Fixes: #2454
The value should be initialized to NULL before calling
g_win32_registry_key_get_value_w(), to ensure that cleanup
can be done unconditionally afterward.
To ensure that the watch is properly re-set every time, call
watch_keys() from the watch callback. Previously the watch was only
renewed after a data update was done in a worker thread, which made
no sense, since the update function was implemented in such a way
that it can (and should) be re-triggered on each key change, until
the changes stop coming, and that can only happen if we renew
the registry watcher right away.
If a key watch is renewed from the key watch callback, it results
in the callback being NULL, since we clear it after we call it.
Rearrange the function to make sure that the changes done by the
callback function are preserved properly.
This function can, in fact, return STATUS_SUCCESS. We shouldn't
assert that it doesn't.
For now interpret it just like STATUS_PENDING (i.e. APC will be called),
see how it goes (it isn't documented how the function behaves in this
case, we have to play it by ear).
Note that while we *can* use a better-documented RegNotifyChangeKeyValue() here,
it communicates back to us via event objects, which means that the registry
watcher would have to interact with the main loop directly and insert its
events (plural; one event per key) there. That would make the API more complicated.
Whereas the internal NT function communicates by calling an APC - we're good
as long as something somewhere puts the thread in alertable state.
Previously, these would have done 2**32 replacements, and the first one
would have consumed 6GB of memory in the process. They now match what
Python `str.replace()` does.
Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/2452
Signed-off-by: Simon McVittie <smcv@collabora.com>
This matches the behaviour of Python `str.replace()`, and avoids carrying
out 2**32 replacements before n wraps around, which is almost certainly
not what we want.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2452
Signed-off-by: Simon McVittie <smcv@collabora.com>
These are taken from another project (steam-runtime-tools) where I
implemented a similar replace method before realising that more recent
GLib versions had g_string_replace().
Signed-off-by: Simon McVittie <smcv@collabora.com>
The `g_file_trash` function fails with the `Unable to find or create trash
directory` error when the global `.Trash` directory exists. This is because
the commit 7f2af262 introduced the `gboolean success` variable to signalize
the detection of the trash folder, but didn't set it in all code branches.
Since for a time this variable was not initialized the bug wasn't visible
when the trash folder existed. The bug became effective after the `success`
variable was initialized with `FALSE` by the commit c983ded0. Let's explicitly
set the `success` variable in all branches to fix the global trash dir
detection.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2439
This is necessary when building glib with icecc. Icecc splits the build
process into two parts. The file is locally preprocessed with
-fdirectives-only to resolve any includes. This adds linemarkers to the
intermediate file. Without the new-line at the end of the file this:
#include "gconstructor_as_data.h"
#include "glib/glib-private.h"
Is turned into this:
const char gconstructor_code[] = "...";# 1 "glib/glib-private.h"
...
The result is a compile error:
In file included from ../glib/gio/glib-compile-resources.c:45:
gio/gconstructor_as_data.h:1: error: stray '#' in program
gio/gconstructor_as_data.h:1: error: expected identifier or '(' before numeric constant
In file included from ../glib/glib/glib-private.h:22,
from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/gwakeup.h:27:1: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:28:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:30:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:32:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:33:42: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:98:3: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:99:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h💯58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:102:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:103:58: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:164:53: warning: file "../glib/gio/glib-compile-resources.c" linemarker ignored due to incorrect nesting
To avoid this, generate gconstructor_as_data.h with a new-line at the end
of the file.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If `g_file_monitor_source_dispatch()` drops the last reference to its
`GLocalFileMonitor`, a deadlock will occur, because disposing the
`GLocalFileMonitor` causes synchronous disposal of the
`GFileMonitorSource`, and hence an attempt to re-lock the already-locked
mutex in the `GFileMonitorSource`.
Fix that by dropping the reference to the `GLocalFileMonitor` after
unlocking.
Diagnosed by Ting-Wei Lan. The bug was originally introduced by me in
commit 592a13b483.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since commit 87e19535fe, the ETag check when writing out a file through
a symlink (following the symlink) has been incorrectly using the ETag
value of the symlink, rather than the target file. This is incorrect
because the ETag should represent the file content, not its metadata or
links to it.
Fix that, and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2417
This fixes a bug where the family flag was ignored in lookup_data_new,
causing the resolver to call getaddrinfo with no hints set when clearly
the family hint should have been set.
When using TAP we want every single line to be one of the following:
- a valid TAP clause
- a comment
- a blank line
Typical explicit test logs are single line comments, but in some cases
we might end up printing debug messages from libraries, and those may
contain multiple lines. When that happens, we break the TAP and fail the
test in conditions entirely outside of our control.
One option to avoid outright failure is to always prepend each line of a
messge with `#`, to ensure that the whole thing is considered a comment.
