It seems that scan-build assumes `n_threads > 0`, but doesn’t assume a
tighter condition than that, and hence assumes that the two loops to
initialise and join the threads have different numbers of iterations.
That’s obviously not the case.
Try and help scan-build out here by marking `n_threads` as `const`. I
don’t know if this will work, but it’s correct regardless.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
scan-build can’t link the types used in `g_variant_builder_init()` with
the (same) types used in `g_variant_builder_end()`, so ends up assuming
that the children have not been initialised.
At runtime, this is prevented by the precondition checks on
`GVSB()->offset` in `g_variant_builder_end()`. scan-build doesn’t notice
that though.
Avoid a scan-build warning by zero-initialising the children array when
running static analysis. Doing this unconditionally would be an
unnecessary performance hit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Recent changes to `GPtrArray` and/or Coverity mean that Coverity is now
assuming that `g_ptr_array_free (my_array, TRUE)` can leak memory. This
is true in the case that `g_ptr_array_ref (my_array)` has been called
elsewhere, but Coverity never actually verifies that.
Very little (or no?) GLib code mixes `g_ptr_array_free()` with
`g_ptr_array_{ref,unref}()`, so this isn’t a problem in practice.
However, it has created a hundred or more false positives in Coverity
(as pointer arrays are widely used within GLib and GIO), which is a
complete pain.
Before taking the dramatic step of ditching Coverity due to its
atrocious false positive rate, let’s try changing the semantics of
`g_ptr_array_free()` only when running under Coverity.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Dynamically, these will only ever be used after they’ve been initialised
due to correct checking of `use_udp` throughout the test. However,
that’s a global variable and the static analyser is assuming it might
change value. So help it out by NULL-initialising the variables so they
can never be used uninitialised.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code was accidentally NULL-terminating the source array rather than
the copy.
This fixes commit ee247c0a2d.
Spotted by the `array-test` installed test in
https://gitlab.gnome.org/GNOME/glib/-/jobs/2047993.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Valgrind has a limit of 500 threads (unless you pass `--max-threads` to
it). Running this test with more threads than that under valgrind seems
unnecessary, so reduce the thread limit when valgrind support is
enabled.
This should fix the following test failure:
```
Use --max-threads=INT to specify a larger number of threads
and rerun valgrind
valgrind: the 'impossible' happened:
Max number of threads is too low
host stacktrace:
==5239== at 0x580427EA: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x58042917: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x58042B80: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x58042BB0: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x58099C0E: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x580E6839: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x5809D3E9: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x58098DB2: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x5809AE97: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==5239== by 0x580E40B0: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable syscall 56 (lwpid 5239)
==5239== at 0x4AB0315: clone (in /usr/lib64/libc-2.33.so)
client stack range: [0x1FFEFFB000 0x1FFF000FFF] client SP: 0x1FFEFFC468
valgrind stack range: [0x1008BAA000 0x1008CA9FFF] top usage: 8776 of 1048576
Thread 2: status = VgTs_WaitSys syscall 202 (lwpid 5268)
==5239== at 0x4AAADDD: syscall (in /usr/lib64/libc-2.33.so)
==5239== by 0x491E2C2: g_mutex_lock_slowpath (gthread-posix.c:1495)
==5239== by 0x491E37C: g_mutex_lock (gthread-posix.c:1519)
==5239== by 0x491E489: g_cond_wait (gthread-posix.c:1578)
==5239== by 0x401436: once_thread_func (once.c:96)
==5239== by 0x48E9F31: g_thread_proxy (gthread.c:829)
==5239== by 0x491DE3A: linux_pthread_proxy (gthread-posix.c:1271)
==5239== by 0x4C002A4: start_thread (in /usr/lib64/libpthread-2.33.so)
==5239== by 0x4AB0322: clone (in /usr/lib64/libc-2.33.so)
client stack range: [0x5022000 0x5820FFF] client SP: 0x5820D28
valgrind stack range: [0x100B267000 0x100B366FFF] top usage: 3544 of 1048576
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1910
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
