This reverts commit 0ddea2d8e2.
The commit was based on the misunderstanding that types
declared with G_DECLARE_FINAL_TYPE are actually non-derivable.
But that is only the case for types defined with
G_DEFINE_FINAL_TYPE.
Fixes: #2661
If we have no nontrivial notify vfunc, and no signal
handlers for notify, we don't need to maintain the
notify queue. No need to notify if nobody's listening.
Check whether an object has a nontrivial notify vfunc
and avoid creating and updating the notify queue if
it doesn't. We know that there can be no notify signal
handlers at this point. No need to notify if nobody's
listening.
We currently keep a flag for whether an object has
ever had any signal handlers. But even if it had signal
handlers, it may not have any notify handlers. Keep that
information separately, so we can speed up property setting.
According to the commit that introduced these
calls (4b334ef8f1), we are checking
the refcount here to avoid calling g_object_ref
when the refcount is 0, in the rare case that
notification would be triggered during finalize.
But we are now freezing notifications during
finalize, and after recent changes, we no longer call
g_object_ref for notification while a freeze is
in place.
We only need to take a ref on the object when
we call out to external code (ie around
->dispatch_properties_changed). If we avoid
the signal emission, we can avoid the ref/unref
too. This is not currently happening, but
might in the future.
A small reorg that reduces the code and matches
what we do for object_get_property.
Note that as a consequence of this change, we now
check the deprecated flag on the redirected property,
not on the original when setting properties. This
matches what we were already doing for getting
properties.
The code that emits property deprecation warnings
rarely runs, and doesn't need to be inlined
everywhere. It is enough to inline the check for
the deprecation flag.
It is safe not to copy arguments here,
because we are not emitting any signals
before we are done setting the values
as properties.
This matches what we do for g_object_new now.
We can safely use the values without copying here.
This is safe because we are not emitting any
signals before we are done setting the values
as properties.
Make the 'complex construction' case more
realistic by adding a string property.
And mark the properties as G_PARAM_STATIC_STRINGS,
since this is commonly done, and doing so will
enable some optimizations.
Also, use g_object_class_install_properties,
to test optimizations that will be tied to using
that function.
xdgmime makes some one-off allocations when being set up. Ignore them in
the suppression file, since they’re not really a leak.
This should fix the contenttype test running under valgrind.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It does some unusual things with memory pages and allocation, and
testing that with valgrind (a) fails and (b) probably isn’t useful
anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a fallback timeout to abort the test if the expected number of
messages aren’t seen in time. However, when running the test under
valgrind it will take longer and sometimes spuriously trigger the
timeout.
There’s no point in having an abort timeout inside the test: the test
runner (Meson) already provides one for us, which we can adjust with a
multiplier when running under valgrind.
So removes the timeout from within the test. This should fix the
gnotification test under valgrind.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They are [currently
failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/2032874) with the
error:
```
1/273 glib:glib / array-test FAIL 0.19s killed by signal 11 SIGSEGV
05:04:16 G_DEBUG=gc-friendly G_TEST_BUILDDIR=/builds/GNOME/glib/_build/glib/tests MALLOC_CHECK_=2 MALLOC_PERTURB_=133 G_TEST_SRCDIR=/builds/GNOME/glib/glib/tests valgrind --tool=memcheck --error-exitcode=1 --track-origins=yes --leak-check=full --leak-resolution=high --num-callers=50 --show-leak-kinds=definite,possible --show-error-list=yes --suppressions=/builds/GNOME/glib/tools/glib.supp /builds/GNOME/glib/_build/glib/tests/array-test
----------------------------------- output -----------------------------------
stderr:
valgrind: m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
------------------------------------------------------------------------------
```
I’m not really sure what that means, but `show-execution-environment.sh`
says the FD soft limit is set to 524288 on the CI machine. That seems
high; on my machine it’s only 1024 (and the valgrind tests pass). So
let’s try 1024.
The valgrind CI has been failing since we most recently upgraded the CI
image to a new version of Fedora.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This re-applies a chunk from commit e63262d49d which was
accidentally lost when upstreaming the commit to xdgmime (as
https://gitlab.freedesktop.org/xdg/xdgmime/-/merge_requests/10).
The upstreamed commit was then re-backported to GLib as a1bfe899ab,
without the missing chunk.
The missing chunk is potentially causing incorrect content type results
for `file://` URIs when used from webkitgtk.
Thanks to Stephen Jung and Michael Catanzaro for investigating.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2639
None of these messages are particularly helpful, but they increase the
overall test log output size, which has to be stored by the CI for every
test run.
With these messages removed, the size of a full test log is reduced from
6.5MB to 1.8MB for me.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This may have been causing an intermittent failure of the pollable test
on BSD, where updating the readable status of a socket takes a bit
longer than on Linux.
```
GLib-GIO-DEBUG: 16:06:41.235: GSocketClient: Starting application layer connection
GLib-GIO-DEBUG: 16:06:41.235: GSocketClient: Connection successful!
Bail out! GLib-GIO:ERROR:../gio/tests/pollable.c:73:check_source_readability_callback: assertion failed (readable == expected): (0 == 1)
```
I have not debugged the test on BSD, though, so this is only a guess.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/2022087
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should make each unit test a bit more self-contained and easier to
verify that they’re independent.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This test is opportunistic in that it’s not possible to detect whether
the race condition has been hit (other than by hitting a deadlock).
So the only approach we can take for testing is to loop over the code
which has previously been known to cause a deadlock a number of times.
The number of repetitions is chosen from running the test with the
deadlock fix reverted.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1941
