We kept seeing the glib testsuite hanging on our CI system in the
testcase for 642026. After some digging it turned out the jenkins slave
was misconfigured and its task limit was too low.
Add an assertion that the test thread has been created to more easily
spot this error condition as opposed to the test simply hanging.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769672
... when tty terminal emulators (such as mintty) are used. This support
is however for Vista and later, so use of such terminals should have
support for ANSI color codes in their outputs, even on Windows 7/8/8.1/
https://bugzilla.gnome.org/show_bug.cgi?id=775468
Windows 10 begins to support color output on the console using ANSI
codes, but a few extra steps are required for this support, so we cannot
just use isatty() and expect colors to work in the outputs.
Instead, we use still use isatty() from the Windows CRT, and then enable
ENABLE_VIRTUAL_TERMINAL_PROCESSING if it returns true.
Also make the invalid parameter handler shared between gmessages.c and
gspawn-win32-helper.c, since it is basically intended to be a no-op stub.
https://bugzilla.gnome.org/show_bug.cgi?id=775468
Signed integer overflow is undefined behaviour, which the undefined
behaviour sanitizer detects.
Previously, if the compiler had implemented this in the obvious way
(overflowing signed multiplication wraps around mod 2**32), we would
have incorrectly classified addresses where one octet was, for example,
(2**32 + 42) as valid IP addresses, by treating that octet as though
it was 42.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
bsearch() is defined to search for a non-null key, so we can't
search for NULL. The undefined behaviour sanitizer picks this up.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
global variables in SystemTap are shared between all SystemTap scripts;
so if scripts are loaded for two versions of GLib (for example, a stable
and a development version), those global variables will conflict.
Avoid that by including the soname’s version in the global variable
names.
https://bugzilla.gnome.org/show_bug.cgi?id=770646
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
The GVariant documentation says you can assume that types of no more
than 32 bits may be assumed to be promoted to int by the usual
promotions. If we're going to document that, we should statically
assert that it's true, i.e. sizeof (int) >= sizeof (int32_t).
All reasonable modern platforms are either ILP32 (32-bit platforms),
LP64 (64-bit Linux, *BSD etc.), or LLP64 (64-bit Windows): there have
been ILP64 platforms in the past, but ILP64 has the compelling
disadvantage that {signed char, short, int} can't possibly provide
all of {int8_t, int16_t, int32_t} unless int is 32 bits long.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters
ISO C allows compilers to make enums smaller than int if their
enumerated values would all fit in the range of a smaller type.
In practice, I suspect that in relevant compilers, all enums whose
values fit in the range INT32_MIN to INT32_MAX (inclusive) are the same
size as int. ISO C allows compiler to break that assumption, but those
that do would break code that works fine in other compilers, making the
compiler look bad, for no significant benefit. I conjecture that such
compilers are not popular.
Let's statically assert that my assumption holds. If all goes well,
GLib will continue to compile on every relevant platform; if it
fails to compile on some platform as a result of this change, then
there are probably a lot of naive uses of enums that need auditing
for this assumption.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Allison Lortie
This code assumes that int is exactly 32 bits, and that pointers
are either 4 or 8 bits, on platforms with __ATOMIC_SEQ_CST.
In practice this is going to be true.
A previous attempt at this assertion placed the G_STATIC_ASSERT
at the top level in gatomic.h, but that broke anjuta, which
redefined __unused__ at the time. These assertions are about the
platform/compiler ABI, so it's sufficient to check them once,
while compiling GLib itself; accordingly, move them to the
implementation.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
g_assert() gets completely compiled out if G_DISABLE_ASSERT is defined,
so applications should not depend on side effects of the expression in
an assertion.
Clarify that the arguments parameter can be zero if the function being
annotated just accepts a string format argument, and no varargs for it
(for example, if it takes a va_list of arguments instead).
Add some links to the GCC documentation for the `format` attribute.
This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
A windows application compiled with -Wl,--subsystem,windows has no
console attached. When started from the start menu for ex, it will crash
when a function attempt to use g_log:
#10 0x00a21b26 in g_logv (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed", args=0x28f2bc "PG"")
#11 0x00a21bb1 in g_log (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed") at gmessages.c:1337
#12 0x00a22bac in g_return_if_fail_warning (log_domain=0xa842e1 <__func__.7668+329> "GLib", pretty_function=0xa84750 <__func__.65002> "g_log_writer_supports_color",
expression=0xa844de <__func__.7668+838> "output_fd >= 0") at gmessages.c:2453
#13 0x00a2239e in g_log_writer_supports_color (output_fd=-2) at gmessages.c:1826
#14 0x00a226ac in g_log_writer_standard_streams (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2254
#15 0x00a2290e in g_log_writer_default (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2357
According to https://msdn.microsoft.com/en-us/library/zs6wbdhx.aspx:
If stdout or stderr is not associated with an output stream (for
example, in a Windows application without a console window), the file
descriptor returned is -2. In previous versions, the file descriptor
returned was -1. This change allows applications to distinguish this
condition from an error.
Check if the stream exists and has an associated descriptor and return
G_LOG_WRITER_UNHANDLED if it's not the case.
Fixes:
https://bugzilla.gnome.org/show_bug.cgi?id=772511
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
It turns out that CommandLineToArgvW() (at least on XP) doesn't end the argv
pointer array with a NULL, but goes straight into argv[0] string data, as per
MSDN. So gspawn-win32-helper.c:protect_wargv() counts argc too high and
overflows.
https://bugzilla.gnome.org/show_bug.cgi?id=772054
Circa 8.38, upstream PCRE (intentionally?) changed behaviour with
respect to whether options set with expressions like "(?i)" at the
top-level were reported via the pcre_fullinfo() API as having been
requested during compilation.
GLib contained a test that verified that these options were indeed
reported as if they had been provided as flags on the API.
Remove that check, and document the no-longer-deterministic behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=767240
I realise this is a contradiction in terms, but it keeps code analysis
tools happy. As spotted by cppcheck, which could not attend GUADEC, but
sends everyone its best wishes anyway.
This should not change the behaviour of the test, unless the test's
behaviour is changed in future. As spotted by cppcheck, which has
impeccable taste and a flair for the unexpected.
At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
Ensure that all the old log handler documentation includes
cross-references to a new section about how to enable structured logging
(tl;dr: #define G_LOG_USE_STRUCTURED).
https://bugzilla.gnome.org/show_bug.cgi?id=769785
