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
Give some example log domains, and recommend that G_MESSAGES_DEBUG is
used universally as the way to enable debug output (rather than having a
separate environment variable per library).
https://bugzilla.gnome.org/show_bug.cgi?id=682794
It’s effectively deprecated if G_LOG_USE_STRUCTURED is defined, or if
the structured logging API is used directly. See the documentation for
rationale.
https://bugzilla.gnome.org/show_bug.cgi?id=769486
g_log_writer_is_journald() works out whether the process’ stderr or
stdout are redirected to journald. While the default writer function
uses this in conjunction with g_log_writer_journald(), that does not
always have to be the case — other writer functions might want to always
write to the journal, and never write to stderr (for example).
Consequently, automatically open the journal socket in
writer_journald(), rather than is_journald().
https://bugzilla.gnome.org/show_bug.cgi?id=769507
journald is a part of systemd which is Linux-only at this time, so only
compile the journald items on Linux only, and just return FALSE for
g_log_writer_is_journald() and G_LOG_WRITER_UNHANDLED for
g_log_writer_journald() on non-Linux.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
Talk to the journal ourselves using sendmsg() instead of linking
against libsystemd for sd_journal_sendv(). At the same time, we
can also avoid excessive copying.
The motivation for dropping the dependency is that we can
then use structured logging e.g. in a flatpak sandbox where
libsystemd may not be present in the runtime.
The code here is inspired by similar code in libvirt.
Currently the docs for GChecksumType are simpy annotated
with 'Since 2.16' which is when GChecksumType was first
introduced. No mention is made of the fact that the
G_CHECKSUM_SHA512 constant was only added much later
in 2.36.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769027
It turns out that the current approach of parsing g_log_structured
varargs is unworkable, because vprintf is not guaranteed to advance
the passed-in va_list. So, we have to reshuffle the argument list
a bit; I've come up with this approach:
g_log_structured (domain, level,
key-value pairs...
"MESSAGE", format,
printf arguments);
This requires a "MESSAGE" key to always be present, and it requires
the "MESSAGE"-format pair to be last, but it avoids an extra NULL
as marker after the key-value pairs. And it can be parsed with a
single pass over the va_list, without any va_copy.
Since we have G_LOG_USE_STRUCTURED, the separate ...structured()
convenience macros are pretty pointless, and I have dropped them
for now.
Look for a macro G_LOG_USE_STRUCTURED, and if it is defined, use
g_log_structured instead of g_log when defining g_warning and friends.
This avoids the extra complication of going through g_logv _and_
g_log_structured to get a message logged; it also lets us pass
the code-related fields.
We don't do this unconditionally (yet), since some users might
rely on the more fine-grained fatality support in g_logv. It has
also been proven problematic in the past to inject a dependency
on bleeding-edge API via a widely-used macro.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
GCC fails to build because of the trailing arguments, not part of the
format:
../../glib/gmessages.c: In function 'g_log_default_handler':
../../glib/gmessages.c:2385:21: error: too many arguments for format
[-Werror=format-extra-args]
NULL);
^
The documentation for `__attribute__((format(...)))` in GCC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
States that the second index must be 0 for functions that are not
available to be checked, like for vprintf-style functions. In this case
it's also appropriate because of the trailing arguments.
The sd-journal API in systemd, upon which the structured logging API is
modelled, also uses 0 as the second argument for the format attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
It turns out that g_info_structured (format, ...) makes
g_info_structured ("Hey!") not work, since it requires at
least one argument after the format string. So shorten
the argument list to just ...
Replace the underlying write_string() call which is the ultimate result
of calling g_log() with a call to g_log_structured(). This means that
all g_log() calls will pass through the structured log handling code
path, as long as they are not already modified or dropped by the g_log()
code (fatal masks, aborts, etc.).
In the case that the default structured log writer is in use, this will
result in the same format of log output to stdout or stderr, as
previously happened. If a non-default writer is in use, it handles the
message as it sees fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
If outputting to a terminal which supports coloured output (rather than,
for example, redirecting to a file). This is only enabled for structured
log messages, where colour output support can be tested. It is not
enabled for non-structured log messages.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
In parallel with g_log(), add a new structured logging API, based around
g_log_structured() and various helper functions which are exposed
publicly to allow programs to build their own logging policies easily,
without having to rewrite a lot of gmessages.c because it’s all
internal.
See the expanded documentation at the top of gmessages.c for some
rationale. See the g_log_structured() documentation for some example
code.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
The macro could be used at initialization time to avoid having an
unitialized dict, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the asv
parameter is actually "GVariant *".
https://bugzilla.gnome.org/show_bug.cgi?id=766370
The macro could be used at initialization time to avoid having an
unitialized builder, especially with g_auto variables.
The macro tries to be a bit more type-safe by making sure that the
variant_type parameter is actually "const GVariantType
*". Unfortunately I have no idea how to make it possible to also pass
a "const gchar *" parameter without warning.
https://bugzilla.gnome.org/show_bug.cgi?id=766370
revents is set in the same function after some lines. This check was
using revents from previous loop. This had the problem of causing two
poll execution for every changes to poll records.
Note that is not possible to move the code after revents is updated
as probably poll_changed is TRUE causing the function to exit.
Adapted from a patch by Frediano Ziglio,
https://bugzilla.gnome.org/show_bug.cgi?id=761102
This reduce the frequency the loop is waked up adding and removing
file descriptors or timeouts.
Considering that to support recursion events are removed from list and
added again this reduce iteration number a lot.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=761102
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
This makes it easier to use GKeyFile from language bindings, and makes
the API more consistent and modern with the new data type available in
GLib.
https://bugzilla.gnome.org/show_bug.cgi?id=767880
The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool. In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.
The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.
Instead of trying to have dtrace run libtool we can have libtool run
dtrace. dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.
There appears to be some prior art for this approach. A quick search
shows that at least QEMU is using this approach. It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.
This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file. I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=725902
The condition removed erroneously excluded UTC-based and DST-less
timezones and so left the GArray with no contents, so GTimeZone functions
returned whatever random garbage was in memory.
Expand the set of available probes, and add a few more output parameters
to some of the existing ones to make them more useful. I do not know if
this breaks any existing stability guarantees for GLib’s SystemTap
tapset, as it is effectively just adding some more local variables in
the user’s probe.
https://bugzilla.gnome.org/show_bug.cgi?id=759813
Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-
On Unix they can contain anything while on Windows
they are always utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=767245
Visual Studio 2008 does not come with stdint.h, so define intmax_t instead
on Visual Studio 2008 so that the code will continue to build. This was
previously unnoticed as building GTK+ since 3.16 requires an
implementation of stdint.h (such as msinttypes), and it took care of the
need of including the stdint.h header here, but people could be very well
using GLib without using GTK+ 3.x.
glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.
This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`. This is due to a namespace clash.
One fix would be to rename the gdb helper files to not clash with
other Python modules. This should be done for all such helper files.
https://bugzilla.gnome.org/show_bug.cgi?id=760186
Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.
This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.
Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=766092
There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.
Instead of finding the GSequence, just walk up
the tree and determine if the iter is the end node.
https://bugzilla.gnome.org/show_bug.cgi?id=749583
Signed-off-by: Garrett Regier <garrettregier@gmail.com>
Later Visual Studio versions does not allow one to define known keywords,
even if they are actually not known to the compiler. Avoid this issue by
checking more conditions before we define inline as __inline:
-We are not building under C++ mode.
-We are on Visual Studio 2013 or earlier.
Where both of these conditions need to hold true.
https://bugzilla.gnome.org/show_bug.cgi?id=765990
