They provide more detailed failure messages, and aren’t compiled out
when building with `G_DISABLE_ASSERT`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When future porting deprecated code to use
g_file_info_get_modification_date_time() we risk a number of breakages
because the current implementation also requires the additional use of
G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC. This handles that situation gracefully
and returns a GDateTime with less precision.
Applications that want the additional precision, are already using the
additional attribute.
(Minor tweaks by Philip Withnall.)
I don’t think these could be hit in practice due to the guarantees of
the type system, but the static analyser doesn’t know that — so make the
assertions clearer to shut it up.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
This should make the code a bit easier to reason about, and squash some
static analysis warnings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
The static analyser can’t yet work out how `g_autofree` works, so
disable those tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
The macros for the probes confuse the static analyser, and are often
called with arguments which the analyser things shouldn’t be used any
more (for example, the address of a block of memory which has just been
freed).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
These squash various warnings from `scan-build`. None of them are
legitimate bugs, but some of them do improve code readability a bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
It's currently marked only as reachable but Valgrind also finds it as
possible:
==18842== 96 bytes in 1 blocks are possibly lost in loss record 2,029 of 2,284
==18842== at 0x4837B65: calloc (vg_replace_malloc.c:762)
==18842== by 0x49614AD: g_malloc0 (gmem.c:129)
==18842== by 0x4A7013B: type_node_any_new_W (gtype.c:439)
==18842== by 0x4A70609: type_node_fundamental_new_W (gtype.c:550)
==18842== by 0x4A7855A: gobject_init (gtype.c:4406)
==18842== by 0x4A78672: gobject_init_ctor (gtype.c:4493)
The previous documentation said this:
g_type_add_interface_static:
"Adds the static interface_type to instantiable_type"
g_type_add_interface_dynamic:
"Adds the dynamic interface_type to instantiable_type"
The above suggests that if one is adding a static interface to a dynamic
object, one should use g_type_add_interface_static because the interface
is static, but the code and usage (with the newly added
G_IMPLEMENTS_INTERFACE_DYNAMIC) imply that this is wrong, and that
what matters is whether the *instanciable_type* is dynamic or not.
Hence this patch moves the "static" and "dynamic" words close to
"instantiable_type".
Closes issue #259
Previously, if a method was not annotated with org.gtk.GDBus.C.UnixFD
then the generated code would never contain GUnixFDList parameters, even
if the method has 'h' (file descriptor) parameters. However, in this
case, the generated code is essentially useless: the method cannot be
called or handled except in degenerate cases where the file descriptors
are missing or ignored.
Check the argument types for 'h', and if present, generate code as if
org.gtk.GDBus.C.UnixFD annotation were specified.
This change will break any existing code which refers to the (useless)
wrappers for such methods. The workaround for such code is to add the
org.gtk.GDBus.C.UnixFD annotation, which will cause the same generated
code to be emitted before and after this change.
If this is found to cause widespread problems, we can explore a
different approach (perhaps emitting a warning from the code generator,
or annotating the symbols as deprecated).
https://gitlab.gnome.org/GNOME/glib/issues/1726
Mark all the memcheck leaks as ‘reachable’, so the suppressions will not
apply if that memory is no longer reachable on exit(). This feature was
introduced in Valgrind 3.9, and is documented here:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The Python runtime is not amenable to Valgrind, and leak checking is a
lot less relevant in Python compared to C.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #487
When running tests under valgrind, the valgrind summary is printed in
stderr, and the TAP output is printed in stdout. The valgrind summary is
useful to include in the GitLab test report, so append it to the
textual failure information for failed tests.
I can’t find a better XML element in the [JUnit
schema](https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd)
for representing it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #487
Add a separate CI job which runs memcheck on the unit tests. This is
done as a separate job from the main build, since we don’t want it to
interact with code coverage at all.
Currently, failure of this job is ignored. Issue #333 will eventually
fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #487
It’s confusing and often doesn’t help the user. Match the error code and
come up with a more UI-appropriate error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the user has `CAP_DAC_OVERRIDE` or similar (for example, if running
the tests as root), the `mkdir-with-parents-permission` test is skipped.
The check for `CAP_DAC_OVERRIDE` was by creating a subdirectory of the
test directory. That subdirectory, however, was never removed, which
caused a ‘directory not empty’ error when trying to delete the test
directory.
Fix that by correctly deleting the subdirectory if skipping the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This suppression is not caught by glib.supp, so add it:
==21145== 32 bytes in 1 blocks are possibly lost in loss record 1,456 of 2,584
==21145== at 0x4837B65: calloc (vg_replace_malloc.c:762)
==21145== by 0x495825E: g_malloc0 (gmem.c:129)
==21145== by 0x4A6B6EB: type_class_init_Wm (gtype.c:2134)
==21145== by 0x4A6D22A: g_type_class_ref (gtype.c:2950)
==21145== by 0x4A6D1DD: g_type_class_ref (gtype.c:2942)
==21145== by 0x4A5C9C6: g_param_spec_enum (gparamspecs.c:2085)
