Any function which requires g_quark_init() to have been called first
cannot be called before the library constructors have finished running.
In particular, this means that g_quark_from_static_string() or
g_intern_static_string() can’t be used to initialize C++ globals.
Do this, rather than adding a conditional call to g_quark_init() to all
these functions, because such a call was previously removed from the
functions to improve performance (quarks are used a lot in the
implementation of GObject for properties and signals). That’s the reason
why g_quark_init() was originally moved out to a library constructor.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1177
Those lists were getting very long. We can’t quite entirely automate the
list generation since Meson doesn’t have a range() function, but we can
at least combine three of them into one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
One test is for _g_win32_subst_pid_and_event().
Two tests for crashing with different exceptions (access violation
and illegal instruction).
And one test for running a debugger.
Install a Vectored Exception Handler[0]. Its sole purpose is to catch
some exceptions (access violations, stack overflows, illegal
instructions and debug breaks - by default, but it can be made to catch
any exception for which a code is known) and run a debugger in response.
This allows W32 glib applications to be run without a debugger,
but at the same time allows a debugger to be attached in case
something happens.
The debugger is run with a new console, unless an environment variable
is set to allow it to inherit the console of the crashing process.
The short list of handleable exceptions is there to ensure that
this handler won't run a debugger to "handle" utility exceptions,
such as the one that is used to communicate thread names to a debugger.
The handler is installed to be called last, and shouldn't interfere
with any user-installed handlers.
There's nothing fancy about the way it runs a debugger (it doesn't even
support unicode in paths), and it deliberately avoids using glib code.
The handler will also print a bit of information about the exception
that it caught, and even more information for well-known exceptions,
such as access violation.
The whole scheme is similar to AeDebug[1] and, in fact, the signal-event
gdb command was originally implemented for this very purpose.
[0]: https://docs.microsoft.com/en-us/windows/desktop/debug/vectored-exception-handling
[1]: https://docs.microsoft.com/en-us/windows/desktop/debug/configuring-automatic-debugging
Commit f975858e86 removed the NULL check in g_cancellable_cancel() by
accident which makes it crash when called with NULL.
Add the check back and add a test so this doesn't happen again.
Fixes#1710
Implement the approach suggested in
https://gitlab.gnome.org/GNOME/glib/merge_requests/276
1. Try to open O_RDWR. On success, pass that fd
2. If EACCESS => fail the trash op, we "need" read-write to successfully trash it
3. If EISDIR => re-open the fd with O_PATH, and pass that (which will fail on snap,
but verify the dir for flatpaks)
Grouping things together makes them easier to find and keep up to date.
This doesn’t modify any of the comments or make any functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
They were originally generated by glib-genmarshal, which documents its
output as being under the same license as the containing project. In
this case, that’s LGPL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Don’t pollute the build directory with files generated by running the
test.
Note that there are still other tests in the gsettings.c test suite
which use the build directory, but fixing them is a bit more involved
than I have time for right now. This is a step in the right direction.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The threads used to iterate at least 10000 times before setting the
"seen thread" flag to true. After porting they inadvertently did that
in the first iteration.
Previously, the test assumed that thread1 and thread2 would be scheduled
enough to set seen_thread{1,2} by the fact that the test runs for a high
number of iterations. On some platforms/schedulers, that’s not true,
which causes the test to spuriously fail.
Fix that by forcing the test to continue iterating until both threads
are seen. If this takes too long, the Meson test runner timeout will be
hit and the test will be terminated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, all three threads would access several global variables
without locking.
Fix that by using atomic accesses to data stored within the
test_closure_refcount() function, which also eliminates the global state
(which would confuse further tests if they were added to this file).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
