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.)
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
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)
