This is really just a very crude and limited conditional breakpoint.
Update the documentation to explain conditional breakpoints in
gdb instead. Also, remove the link to refdbg, which appears dead.
https://bugzilla.gnome.org/show_bug.cgi?id=719687
Usually async methods copy/ref its arguments so caller can
forget about them. g_file_replace_contents_async() and
g_output_stream_write_async() are exceptions.
https://bugzilla.gnome.org/show_bug.cgi?id=690525
The desktop-files directory contains a mimeapps.cache file
that was not installed as data for installed tests, causing
the file measure test to fail only in when installed.
Make the testcase compare the byte size to what is reported
by du. Also add a test for the async api, and mak eit test
the progress reporting callback.
Comparing the code generated for the setter and other methods without
(real) return value, I noticed that the setter does not unref the
gvariant it gets.
https://bugzilla.gnome.org/show_bug.cgi?id=719472
This function turns a varargs argument list into a string array,
but forgets to NULL-terminate it. This function was not covered
by unit tests...so it was broken.
The test reveals that there's something fishy with this monitor.
One has to call g_app_info_get_all() for it to start working,
and then it only works once.
The previous patch to simplify the GSettings commandline tool by making
more use of global variables went a bit too far and broke 'gsettings
monitor' when used without a specific key.
Fix that up again.
Take this test out of 'make check'. It's causing problems for a lot of people
due to fact that it's essentially a forkbomb. It's causing failures for Debian
on ARM and it's DoSing coredumps to system crash collectors.
The conditional only covers registration of the master, not the
subprocess parts. This is because g_test_slow() always return FALSE in
the subprocesses, so they would fail to run if we didn't register them
unconditionally.
When calculating the array sizes in get_contents_stdio(), there is a
possibility of overflow for very large files. Rearrange the overflow
checks to avoid this.
The code already handled some possibilities of files being too large, so
no new GError has been added to handle this; the existing
G_FILE_ERROR_FAILED is re-used.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
This probably won’t crash, as it can only happen if (size == 0), but
add a check to be safe, and to shut up the static analyser.
This case can be reached with the following call:
gvs_read_unaligned_le(NULL, 0)
which can be called from:
gvs_tuple_get_child(value, index_)
with (value.data == NULL) and (value.size == 0).
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
The static analyser (correctly) considers a type check to fail if the
variable is NULL. In this case, the address must be non-NULL as no error
was thrown by g_socket_connection_get_remote_address(), but the static
analyser doesn’t know this.
Add a non-NULL assertion anyway, both to shut the analyser up, and
because it’s good extra testing.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
These prevent some false positives from the static analyser which are
caused by it not inspecting the invariants of
g_subprocess_communicate[_utf8]_finish() (i.e. that stdout and
stdout_str will always be set unless an error was returned).
They’re also good testing anyway.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
If the initial part of the header (‘MIME-TreeMagic’) is valid, but the
following line does not start with ‘[’ (i.e. is not a valid section
line), insert_matchlet() will be called with a NULL match pointer, and
will crash with a NULL pointer dereference.
Fix this by bailing out if a valid section line isn’t encountered before
the first insert_matchlet() call (i.e. between the header line and the
first data line).
Note that this has not been tested against a real treemagic file; the
fix is purely theoretical.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
