This especially has the effect that any GWeakRefs to the object will not
necessarily be set to NULL yet if called as part of
g_object_run_dispose() and not as part of g_object_unref().
There’s no explicit guarantee that any of these functions are safe to
use on untrusted data, but it does no harm to test them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `nameprep()` function in `ghostutils.c` is quite complex, and does a
lot of allocations. This means it can take a long time on long hostnames
(on the order of 10KB long). Hostnames should never be that long,
though, so impose some loose length limits.
oss-fuzz#27371
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There were a couple of places where the return value wasn’t checked, and
hence failure could not be noticed.
Coverity CIDs: #1159435, #1159426
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s possible that GLib will eventually be compiled against a version of
libc which supports `close_range()` (hence `HAVE_CLOSE_RANGE` will be
defined), but then run against an older kernel which doesn’t support it.
In this case, we want to fall back to `fdwalk()`, which should work on
such systems.
This is what cpython does: 3529718925/Python/fileutils.c (L2227)
Spotted by Allison Karlitskaya in !1688.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The function declaration we use changed a bit since then.
In particular, some arguments became const. See following commit.
libselinux-2.2 was released on 20131030, and is widely available in
all major stable distributions.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
From:
9eb9c93275
"we found that the const security_context_t declarations in libselinux
are incorrect; const char * was intended, but const security_context_t
translates to char * const and triggers warnings on passing const char *
from the caller. Easiest fix is to replace them all with const char *."
And later marked deprecated in commit:
7a124ca275
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They extend the behavior of, respectively, -p and -s options of the
glib test framework
Currently test suite are only run for one level under -p path, for
example, testfilemonitor -p /monitor would execute the following tests:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
With the --run-prefix the sub-test suite file will be executed:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
The --skip-prefix and run-prefix seems symmetrical, but there is a
difference with skip towards run:
--skip-prefix will use a prefix while --run-prefix only work for a valid test path.
For example and for the following test family:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
while --run-prefix /mon will not execute anything, --skip-prefix /mon
will skip all of these tests.
See #2238 which references this change.
- Add a test for parsing FILE scheme from uri
It had taken from GST test_protocol_case
- Add a split uri test with encoded spaces in its path
It had taken from GST test_uri_get_location
- Add tests for g_uri_is_valid
It had taken from GST test_uri_misc
Note that the 4 followings uri failed under gst_uri_is_valid but not
under g_uri_is_valid
B:\\foo.txt
B:/foo.txt
B://foo.txt
B:foo.txt
- Add tests for g_uri_split
It had taken from GST test_url_parsing
- Add tests for test_uri_normalize and test_uri_parsing_relative
The test URI had been taken from GST test_url_normalization
- Add tests for test_uri_iter_params
It had taken from GST test_url_unescape_equals_in_http_query
Closes#2150
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
This was inconsistently handled before and only explicit unbinding or
finalizing the binding would've previously released the transform
function. If the source/target were finalized while more strong
references to the binding still existed then the transform function
would stay alive and only the binding itself would be deactivated.
Unbinding can happen from one thread while a property notification is
being handled concurrently in another one.
To solve this, introduce a reference counter for the transform function
that ensures that it always stays valid while in use and protect access
to the one stored inside the binding with the unbind mutex.
It's possible for g_binding_unbind() to be called at the same time as
one (or both) of source and target are being finalized. The resulting
unbinding needs to be protected with a mutex to ensure that it only
happens exactly once.
As the first reference is owned by both weak notifies and the caller of
g_object_bind_property(), additional indirections are needed to ensure that
unreffing the first reference after creation still unbinds the binding
as before. This seems to be a common code pattern and how this was
intended to be used, but is only safe in single-threaded contexts as it
relies on both the source and target object to be still alive.
Add a lot of comments to the code about all these dependencies and a
couple of assertions to ensure they hold valid.
Also document that inconsistent reference ownership handling of
g_binding_unbind() that makes it unfit for automatically generated
language bindings.
It still works, and deprecating it would be quite disruptive (as it’s
used in headers), so amend the documentation to point people to
`G_NORETURN` instead.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #994
gobject/gobject.c: In function ‘g_object_new_internal’:
gobject/gobject.c:1962:25: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1962 | for (j = 0; j < n_params; j++)
| ^
gobject/gobject.c:1989:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1989 | for (i = 0; i < n_params; i++)
| ^
gobject/gobject.c: In function ‘g_object_new_with_custom_constructor’:
gobject/gobject.c:1836:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1836 | for (j = 0; j < n_params; j++)
| ^
gobject/gobject.c:1914:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1914 | for (i = 0; i < n_params; i++)
| ^
gobject/gobject.c: In function ‘g_object_class_install_properties’:
gobject/gobject.c:766:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
766 | for (i = 1; i < n_pspecs; i++)
| ^
gobject/gtype.c: In function ‘g_type_interface_add_prerequisite’:
gobject/gtype.c:1607:21: error: comparison of integer expressions of different signedness: ‘guint’ {aka ‘unsigned int’} and ‘int’
1607 | for (i = 0; i < prerequisite_node->n_supers + 1; i++)
| ^
The problem occurs because we keep a pointer inside the allocated block,
instead of a pointer to the start of the block. This memory exists for
the lifetime of the application, so let's silence it.
This is probably abuse of VALGRIND_MALLOCLIKE_BLOCK(), which is really
intended for use in memory allocators, but gtype.c already uses it in
two other places, and it's a practical solution. I wrote another larger
fix for this issue that involves keeping an array of extra pointers when
running under valgrind. This is simpler.
Fix suggested by Philip Withnall
```
==180238== 16 bytes in 1 blocks are possibly lost in loss record 3,078 of 16,075
==180238== at 0x483BB1A: calloc (vg_replace_malloc.c:762)
==180238== by 0x5489495: g_malloc0 (gmem.c:132)
==180238== by 0x5489754: g_malloc0_n (gmem.c:364)
==180238== by 0x53FDBEE: type_set_qdata_W (gtype.c:3722)
==180238== by 0x53FDEE8: type_add_flags_W (gtype.c:3787)
==180238== by 0x53FC348: g_type_register_fundamental (gtype.c:2662)
==180238== by 0x53D969B: _g_enum_types_init (genums.c:124)
==180238== by 0x53FF058: gobject_init (gtype.c:4432)
==180238== by 0x53FF082: gobject_init_ctor (gtype.c:4493)
==180238== by 0x4010F29: call_init.part.0 (dl-init.c:72)
==180238== by 0x4011030: call_init (dl-init.c:30)
==180238== by 0x4011030: _dl_init (dl-init.c:119)
==180238== by 0x4002149: ??? (in /usr/lib64/ld-2.30.so)
```
Fixes#2076
