A reader might think "how would a process terminate without an exit
status?", or equivalently, "what harm would it do if I assume every
termination has an exit status?" without this reminder that termination
with a signal is also reasonably common.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Unix platforms, wait() and friends yield an integer that encodes
how the process exited. Confusingly, this is usually not the same as
the integer passed to exit() or returned from main(): conceptually it's
an integer encoding of this tagged union:
enum { EXITED, SIGNALLED, ... } tag;
union {
int exit_status; /* if EXITED */
struct {
int terminating_signal;
bool core_dumped;
} terminating_signal; /* if SIGNALLED */
...
} detail;
Meanwhile, on Windows, wait statuses and exit statuses are
interchangeable.
I find that it's clearer what is going on if we are consistent about
referring to the result of wait() as a "wait status", and the value
passed to exit() as an "exit status".
GSubprocess already gets this right: g_subprocess_get_status() returns
the wait status, while g_subprocess_get_exit_status() genuinely returns
the exit status. However, the GSpawn family of APIs has tended to
conflate the two.
Confusingly, g_spawn_check_exit_status() has always checked a wait
status, and it would not be correct to pass an exit status to it; so
let's deprecate it in favour of g_spawn_check_wait_status(), which
does the same thing that g_spawn_check_exit_status() always did.
Code that needs backwards-compatibility with older GLib can use:
#if !GLIB_CHECK_VERSION(2, 69, 0)
#define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
#endif
Signed-off-by: Simon McVittie <smcv@collabora.com>
Confusingly, g_spawn_check_exit_status() takes a wait status, not an
exit status, so passing g_subprocess_get_exit_status() to it is
incorrect (although both encodings happen to use 0 to encode success
and a nonzero value to encode failure, so in practice this probably
had the desired effect).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Following on from the previous commit, some explicit
`g_main_context_wakeup()` calls were missing from the test code which
only uses `GMainContext`.
Add them, and also add some assertions to check that these functions are
being called in the expected thread (as the code comments say).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The tests in `gdbus-names.c` use a mixture of `GMainLoop` and iterating
a `GMainContext` directly. Some of the helper functions based around the
`OwnNameData` struct use the `loop` `GMainLoop` even when called from
tests like `watch_with_different_context()` which themselves use
`GMainContext` directly.
Thus, it’s possible for the `GMainLoop` to not be running, while the
test is iterating on `g_main_context_iteration()`. In this case,
`g_main_loop_quit()` is a no-op and will not wake up the `GMainContext`.
This causes the test to livelock in around 1 in 1200 test runs.
Fix this by adding an explicit `g_main_context_wakeup()` call after each
`g_main_loop_quit()` call. A more comprehensive fix would be to port all
the tests in this file to iterating `GMainContext` directly, and drop
all the `GMainLoop` usage, but I don’t have time for that right now.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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>
Relax the requirement for the test to only be compiled/run under gcc,
since a version of LLVM was released which supports `--add-symbol`.
`objcopy` should be overrideable to be `llvm-objcopy` by using a machine
file as per https://mesonbuild.com/Machine-files.html#binaries.
Suggested and tested by Grigory Vasilyev.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2423
This works in the same way as g_variant_take_ref(), and for the same
reason.
Updated and Rebased by Nitin Wartkar <nitinwartkar58@gmail.com>
Closes#1112
This is from the wrapdb, at version 8.37-2. This version includes
changes needed for the subproject to work correctly in GLib: enabled
Unicode support. Earlier wrap versions won’t work.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962
Zero is a valid TLS index so it needs to be checked. It’s also the
integer used to indicate that no TLS has been allocated yet, so it can’t
be used as a TLS identifier.
Incorporates changes from Philip Withnall.
Fixes: #2058
Clarify that the terms ‘GUID’ and ‘UUID’ are used interchangeably in the
context of D-Bus, and that neither of them are an RFC 4122 UUID.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If there were more subpatterns in the regex than matches (which can
happen if one or more of the subpatterns are optional),
`g_match_info_fetch()` was erroneously returning `NULL` rather than the
empty string. It should only return `NULL` when the `match_num`
specifies a subpattern which doesn’t exist in the regex.
This is complicated slightly by the fact that when using
`g_regex_match_all()`, more matches can be returned than there are
subpatterns, due to one or more subpatterns matching multiple times at
different offsets in the string.
This includes a fix for a unit test which was erroneously checking the
broken behaviour.
Thanks to Allison Karlitskaya for the minimal reproducer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #229
Rather than predicating the test on whether the system PCRE is being
used, use a more specific version comparison which should work
regardless of whether the system or internal copy of libpcre is being
used.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962
Also move env setup earlier in the test, to ensure that
the child gets the envvars during initialization.
Also, don't look for exception codes in stderr, since
OutputDebugStringA() doesn't dump stuff there.
Use OutputDebugStringA() instead of fprintf.
The goal for this code is to inform the person running the debugger
about the exception that caused the debugger to be attached.
This is useful for debugging with gdb, because gdb does not catch Windows
exception information (it just displays "Segmentation fault").
OutputDebugStringA() ensures that the output goes to the debugger,
and the (ab)use of strcpy() with a stack-allocated buffer ensures
that we do not allocate anything while the crash handler is running,
nor to we call CRT functions that can be reasinably expected to allocate
anything.
Since VEH is invoked when an exception occurs (which, for us,
is mostly when the program is already crashing), we should
try to avoid doing much processing at that point. Since these
things (debugger commandline, a list of extra exceptions to catch)
are known in advance, set them up during initialization.
The first is to avoid any non-trivial code in the crash handler.
The second is to avoid the use of quarks and hash tables (brought
in by g_getenv()) during GLib initialization.
