Bug #786580 triggered this warning to show up in the appinfo tests if
run on a machine where no terminal except xterm is installed (for
example, a build machine). Since we didn’t warn before if xterm but no
other terminals were installed, it seems reasonable to downgrade the
warning to a debug message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790914
Otherwise there is a race in finalising the GSourceCallback if one
thread is finishing off a g_main_dispatch() while another thread is
destroying the GSource which owns the GSourceCallback.
A helgrind log:
==21707== Possible data race during write of size 4 at 0x54EACB0 by
thread #12
==21707== Locks held: none
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECD953: g_main_dispatch (gmain.c:3081)
==21707== by 0x4ECE667: g_main_context_dispatch (gmain.c:3673)
==21707== by 0x4ECE859: g_main_context_iterate (gmain.c:3744)
==21707== by 0x4ECEC7F: g_main_loop_run (gmain.c:3938)
==21707== by 0x41C197: some_thread (some-code.c:224)
==21707==
==21707== This conflicts with a previous write of size 4 by thread #5
==21707== Locks held: 1, at address 0x54CF320
==21707== at 0x4ECC174: g_source_callback_unref (gmain.c:1528)
==21707== by 0x4ECB86F: g_source_destroy_internal (gmain.c:1178)
==21707== by 0x4ECB9D4: g_source_destroy (gmain.c:1227)
==21707== by 0x41CF09: some_other_thread (some-other-code.c:410)
https://bugzilla.gnome.org/show_bug.cgi?id=737677
SystemTap tapsets are architecture-specific, as they include the full
path to the .so file for each probe they reference. Hence, we should
install them in an architecture-specific path, or multiarch systems will
suffer from collisions between them.
A better long-term solution, using $libdir rather than the
non-architecture-specific $datadir, is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264; but this will do
for now.
https://bugzilla.gnome.org/show_bug.cgi?id=662802
If we can’t convert the inotify event mask into a GFileMonitorEvent enum
value, don’t propagate it to GLocalFileMonitor, since it hits an
assertion failure in that case.
This should no longer be possible since the previous commit to ignore
IN_Q_OVERFLOW events, but we might as well change this just in case
other bugs crop up in event mask handling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
There’s not much we can do about them, and if they go unhandled, they
can propagate through to g_file_monitor_source_handle_event() and cause
assertion failures due to not mapping to a GFileMonitorEvent.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
It seems that when GLib is compiled without CFLAGS=-g, gdb can’t work
out the size of __glib_assert_msg, so assumes it’s 4 bytes — even on
64-bit systems. This causes it to not read the most significant 4 bytes
of the assertion message pointer, and hence it can’t print the stored
assertion message. This causes assert-msg-test to fail.
The upstream gdb bug is
https://sourceware.org/bugzilla/show_bug.cgi?id=22501.
Work around that by referencing and dereferencing __glib_assert_msg so
that gdb treats it as a pointer of sizeof(char*) rather than of the size
it incorrectly calculated from the library’s symbol table (or through
some other mystical process).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782057
While gio module extension is loaded a new GProxyResolverPortal is
created to query whether it's supported. We always return FALSE when not
aunder flatpak, so we don't need to connect to the session bus in that
case. Add a helper ensure_resolver_proxy() that returns TRUE when the
proxy is created and use it in is_supported() instead of creating the
proxy unconditionally in the instance initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=790894
This removes the use of defined() in a macro expansion, which may not be
portable to some pre-processors. Instead, we hoist the defined check
outside the macro expansion.
https://bugzilla.gnome.org/show_bug.cgi?id=790877
The example code defines an interface with three methods. The preceding text
reads 'This interface defines two methods'. This appears to be because the
example code was changed without updating the surrounding text.
https://bugzilla.gnome.org/show_bug.cgi?id=790830
We can’t guarantee that the builddir we’re generating in actually exists
— if doing a clean build with builddir ≠ srcdir, and there are no other
rules which generate build products in builddir, the .test generation
rule can fail. This happens for flatpak-builder.git for me.
Try to avoid that by explicitly creating the builddir.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790785
Since automake 1.11.2, it’s recommended to use the prefixed version and
leave the unprefixed version for users to override. Since we depend on
automake 1.13.3, we should be doing this.
Based on a patch by Sam Spilsbury <smspillaz@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Noticed these were missing when handling bug #733648. Add a few missing
tests to improve coverage.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are some GDateTime tests which need to be skipped if changing the
locale fails. Use g_test_skip() to do that, rather than just a
human-readable message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Passing -z nodelete without the shared library flags on Solaris results in
ld: fatal: option '-z nodelete' is incompatible with building a dynamic executable
which causes the configure test to falsely report its not supported.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776195
Specifically controlling the location of this file, rather than simply
using $libdir, allows one to avoid conflicting with the same default
location as the gnulib localcharset module uses.
https://bugzilla.gnome.org/show_bug.cgi?id=346816
It is outdated and no longer effectively used. It was originally in
place to prevent rebuilding generated files (from a tarball) if the
right build tools (awk, Perl, indent) were not available. However, we no
longer use indent, we have hard-required awk for a while, and the only
places the @REBUILD@ substitution was still used were for
glib-genmarshal, which has recently been rewritten in Python (so no
longer depends on whether Perl is available).
Drop the whole lot.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=694723
After the build system rework in commit f9eb9e testgobject fell through
the cracks and was not built since then.
Re-enable it, even if it is currently failing due to commit 31fde56.
(Tweaked by Philip Withnall to add meson.build support.)
https://bugzilla.gnome.org/show_bug.cgi?id=701156
Commit 31fde56 changed the way the private data is laid out in memory by
putting it *before* the instance data to keep the offsets fixed
regardless of the number of many subclasses.
This means that the invariant testgobject was verifying is no longer
true and the failing tests can be safely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=701156
On Solaris sigset_t is only defined in /usr/include/sys/signal.h
(included from /usr/include/signal.h) if _XPG4_2 is defined. If
it's not defined, you need to include /usr/include/sys/select.h.
http://bugzilla.gnome.org/show_bug.cgi?id=562334
fstype is a const char*, and is passed to
g_file_info_set_attribute_string(), which takes a copy of it. There’s no
need to g_strdup() the FS type from various statfs/statvfs buffers
beforehand, given that the buffers are valid for the duration of this
function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=679347
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
This adds g_file_load_bytes() to make it more convenient to
load the contents of a GFile as GBytes.
It includes a special casing for gresources to increase the
chances that the GBytes directly references the embedded data
instead of copying to the heap.
https://bugzilla.gnome.org/show_bug.cgi?id=790272
In the vast majority of cases, we can avoid temporary
allocations for paths in g_resources_enumerate_children().
In the case we need to add a suffix "/", we can usually just
build the path on the stack. In other cases, we can completely
avoid the strdup, which appears to only have been added for
readability. If the path is really long, we fallback to doing
what we did before, and use g_strconcat().
In the case of Builder, this saved 5.3mb of temporary
allocations in the process of showing the first application
window.
https://bugzilla.gnome.org/show_bug.cgi?id=790275
Previously, the path canonicalization for resources had liberal use of
strlen() and memmove() while walking through the path. This patch avoids
any secondary strlen() and removes all use of memmove().
A single allocation is created up front as we should only ever need one
additional byte more than then length of the incoming path string.
To keep the implementation readable, the mechanics are kept in external
functions. memrchr() was not used due to its lack of portability.
This is faster in every test case I've tested. Paths that contain
relative ../ have the most speedup.
https://bugzilla.gnome.org/show_bug.cgi?id=790310
