Due to load, particular traits of the architecture, or other circumstances, the
/mainloop/timeouts sometimes manages to call the "every
100 ms" timer loop only 9 times in 1050 ms.
This is an inherent race-condition in the test; allow it some slack and accept
9 times as well.
https://bugzilla.gnome.org/show_bug.cgi?id=678959
Sometimes the poll duration in the /socket/timed_wait test is slightly lower
than the requested 100000, causing failures like
ERROR:/build/buildd/glib2.0-2.33.2/./gio/tests/socket.c:619:test_timed_wait:
assertion failed (poll_duration > = 100000): (99240 >= 100000)
FAIL
Adjust the test to also allow some jitter in the "too small" direction, similar
to the already existing span for "slightly too large".
https://bugzilla.gnome.org/show_bug.cgi?id=678881
Rather than having a single priority-ordered list of GSources, store a
list of queues of each priority level. This means that adding a source
is now O(n) in the number of unique priority levels currently being
used, rather than O(n) in the total number of sources.
https://bugzilla.gnome.org/show_bug.cgi?id=619329
A child source does not have a priority of its own; it must have the
same priority as its parent. Enforce this in
g_source_set_priority_unlocked().
https://bugzilla.gnome.org/show_bug.cgi?id=619329
The current note makes it look like the marshaller code generation has
been deprecated in favour of the libffi-based generic marshaller; this
is not the case, so we should probably clarify the point a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=677235
The old _pcre_ucp_othercase() function was wrong in returning
NOTACHAR (0xffffffff) for characters that aren't changed by upper-
and lower-casing. This led to PCRE internally using incorrect (or
at least inefficient) character classes when using G_REGEX_CASELESS.
E.g. [Z-\x{100}] turned into:
[Z\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{39c}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{178}z-\x{101}]
instead of the expected and efficient
[Z\x{39c}\x{178}z-\x{101}]
https://bugzilla.gnome.org/show_bug.cgi?id=678273
In general, code using g_slist_delete_link() is broken, because it
potentially requires an O(n) traversal. Just switch to GList in this
case.
The performance hit here was exacerbated by the fact that we were
holding a mutex that needed to be accessed by all threads.
https://bugzilla.gnome.org/show_bug.cgi?id=678576
This is a regression introduced by:
commit 6ac8e6108c
Author: Matthias Clasen <mclasen@redhat.com>
Date: Tue Jun 14 10:12:46 2011 -0400
Don't leak resources in error cases
They make a full (deep) copy of a list.
In contrast with g_[s]list_copy(), these functions take a function as a argument
to make a copy of each list element, in addition to copying the list container itself.
The functions g_[s]list_copy() were reimplemented to just call the new functions
with NULL as the function argument, which will behave like current implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=675024
make sure the proxy threads are in the "waiting for a connection"
state when we do the final cleanup, or else there are race conditions
involving which thread processes the GCancellable cancellation first.
The bash-completion code nowadays expects completion files to
be installed in /usr/share/bash-completion/completions, and
expects them to be named like the command they are completing
for.
https://bugzilla.gnome.org/show_bug.cgi?id=677782
Apparently the C4819 warnings appear due to a bug on Visual C++ on DBCS
locales, so re-enable this.
Add a note in the Visual C++ Readme.txt's regarding this.
