Commit Graph

20877 Commits

Author SHA1 Message Date
Matej Urbančič
5e954434a3 Updated Slovenian translation 2020-06-16 18:58:32 +02:00
Matej Urbančič
f13349b90e Updated Slovenian translation 2020-06-10 14:09:36 +02:00
Matej Urbančič
b3df6c238b Updated Slovenian translation 2020-06-05 09:12:51 +02:00
Philip Withnall
6e70c1f20d 2.62.6
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2.62.6
2020-03-18 12:56:23 +00:00
Sebastian Dröge
46a6279fd4 Merge branch 'backport-socks5-fixes-glib-2-62' into 'glib-2-62'
Backport SOCKS5 fixes to glib-2-62

See merge request GNOME/glib!1411
2020-03-10 15:48:54 +00:00
Philip Withnall
eab5d7b133 gsocks5proxy: Fix SOCKS5 username/password authentication
It was checking for the main SOCKS5 version number, rather than the
subnegotiation version number. The username/password authentication
protocol is described in https://tools.ietf.org/html/rfc1929.

Spotted and diagnosed by lovetox.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1986
2020-03-10 15:22:29 +00:00
Philip Withnall
5e28025650 gsocks5proxy: Return G_IO_ERROR_PROXY_NEED_AUTH if anonymous auth fails
If a username and password are specified by the caller, `GSocks5Proxy`
tells the server that it supports anonymous *and* username/password
authentication, and the server can choose which it prefers.

Otherwise, `GSocks5Proxy` only says that it supports anonymous
authentication. If that’s not acceptable to the server, the code was
previously returning `G_IO_ERROR_PROXY_AUTH_FAILED`. That error code
doesn’t indicate to the caller that authentication might succeed were
they to provide a username and password.

Change the error handling to make that clearer. A fuller solution would
be to expose more of the method negotiation in the `GSocks5Proxy` API,
so that the caller can specify ahead of time which authentication
methods they want to use. That can follow in issue #2059 though.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1988
2020-03-10 15:22:29 +00:00
Marek Černocký
e6db3bc9f4 Updated Czech translation 2020-03-07 01:02:47 +01:00
Philip Withnall
2f872eb3c7 Merge branch 'backport-1390-array-copy-crash-glib-2-62' into 'glib-2-62'
Backport !1390 “garray: Fix copying an array with reserved elements” to glib-2-62

See merge request GNOME/glib!1393
2020-02-28 13:46:24 +00:00
Philip Withnall
6b43533c7d Merge branch 'backport-1373-win32-exceptions-glib-2-62' into 'glib-2-62'
Backport !1373 win32 exception fixes to glib-2-62

See merge request GNOME/glib!1378
2020-02-28 13:32:40 +00:00
Philip Withnall
427667f517 Merge branch 'backport-1254-gio-module-path-fix-glib-2-62' into 'glib-2-62'
Backport !1254 “giomodule: gio modules are no longer installed in bindir on MSVC” to glib-2-62

See merge request GNOME/glib!1380
2020-02-28 13:25:06 +00:00
Philip Withnall
d3c92327ce garray: Fix copying an array with reserved elements
Spotted by Mohammed Sadiq. `g_array_copy()` was doing a `memcpy()` of
the data from the old array to the new one, based on the reserved
elements in the old array (`array->alloc`). However, the new array was
allocated based on the *assigned* elements in the old array
(`array->len`).

So if the old array had fewer assigned elements than allocated elements,
`memcpy()` would fall off the end of the newly allocated data block.
This was particularly obvious when the old array had no assigned
elements, as the new array’s data pointer would be `NULL`.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #2049
2020-02-28 12:52:15 +00:00
Nirbheek Chauhan
3a3b99dd52 gwin32: Do not register a crash handler unless requested
Fixes https://gitlab.gnome.org/GNOME/glib/issues/2025
2020-02-28 12:51:34 +00:00
Nirbheek Chauhan
4dfd04d79e gwin32: Do not ignore exceptions when running under a debugger
We're supposed to return `EXCEPTION_CONTINUE_SEARCH` here to tell the
vectored exception handler (VEH) to move on to the next exception
handler instead of skipping them all and trying to continue execution.

Swallowing exceptions messes up CLR exception processing and breaks C#
code. For more details, see:
https://blogs.msdn.microsoft.com/jmstall/2006/05/24/beware-of-the-vectored-exception-handler-and-managed-code/

Fixes https://gitlab.gnome.org/GNOME/glib/issues/2025
2020-02-28 12:51:34 +00:00
Nirbheek Chauhan
846b548f0b giomodule: gio modules are no longer installed in bindir on MSVC
Ever since the port to Meson, gio modules (f.ex., by glib-networking)
are installed inside libdir both for MinGW and MSVC.
2020-02-28 12:51:07 +00:00
Simon McVittie
225a8f8c4a Merge branch 'backport-test-fix-glib-2-62' into 'glib-2-62'
Backport part of !1375 “tests: Skip g-file-info-filesystem-readonly test if bindfs fails” to glib-2-62

See merge request GNOME/glib!1394
2020-02-28 12:48:23 +00:00
Philip Withnall
5ac6c78499 tests: Skip g-file-info-filesystem-readonly test if bindfs fails
bindfs is part of the setup process, so if it fails (as can happen if
the `fuse` kernel module has not been loaded — not much we can do about
that) then skip the test.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-02-27 15:57:02 +00:00
Daniel Șerbănescu
275b8ba926 Update Romanian translation 2020-02-24 18:41:32 +00:00
Philip Withnall
86c2832f95 2.62.5
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2.62.5
2020-02-18 10:58:25 +00:00
Sebastian Dröge
c2e03c69d6 Merge branch 'backport-1357-unix-mount-monitor-thread-safety' into 'glib-2-62'
Backport !1357 “gunixmounts: Make GUnixMountMonitor thread-safe” to glib-2-62

See merge request GNOME/glib!1371
2020-02-18 10:46:17 +00:00
Ondrej Holy
a69f233ec7 gunixmounts: Remove pending sources when finalizing
mtab_file_changed_id is	not currently removed when finalizing, which
could potentially lead to segfaults. Let's remove the source when
finalizing to avoid this.
2020-02-18 10:18:59 +00:00
Ondrej Holy
b1aa9cd1ae gunixmounts: Prevent race when mtab file changed
mtab_file_changed_id might be set on thread default context, but it is
always cleared on the global context because of usage of g_idle_add. This
can cause the emission of redundant "mounts-change" signals. This should
not cause any issues to the client application, but let's attach the idle
source to the thread-default context instead to avoid those races for sure.
2020-02-18 10:18:59 +00:00
Ondrej Holy
1cd2ae372c gunixmounts: Prevent invalid time_read timestamps
The `get_mounts_timestamp()` function uses `mount_poller_time` when
`proc_mounts_watch_source` is set, but the `mount_poller_time` is not
initialized in the same time as `proc_mounts_watch_source`. This may
cause that zero, or some outdated value is returned. Let's initialize
`mount_poller_time` to prevent invalid values to be returned.
2020-02-18 10:18:59 +00:00
Ondrej Holy
cb1da9dc0a gunixmounts: Make GUnixMountMonitor thread-safe
The Nautilus test suite often crashes with "GLib-FATAL-CRITICAL:
g_source_is_destroyed: assertion 'g_atomic_int_get (&source->ref_count)
> 0' failed" if it is started with "GIO_USE_VOLUME_MONITOR=unix". This
is because GUnixMountMonitor is simultaneously used from multiple
threads over GLocalFile and GVolumeMonitor APIs. Let's add guards for
proc_mounts_watch_source and mount_poller_time variables to prevent
those crashes.

Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2030
2020-02-18 10:18:59 +00:00
Philip Withnall
6e8b8b0f8c Merge branch 'backport-1369-relative-paths-glib-2-62' into 'glib-2-62'
Backport !1369 “build: Rework path construction to reliably add prefix” to glib-2-62

See merge request GNOME/glib!1370
2020-02-17 19:53:40 +00:00
Sebastian Dröge
5fab0663ca Merge branch 'backport-1314-tz-parsing-glib-2-62' into 'glib-2-62'
Backport !1314 “gtimezone: fix parsing of Julian day in POSIX TZ format” to glib-2-62

See merge request GNOME/glib!1323
2020-02-17 19:03:41 +00:00
Sebastian Dröge
807dbde8a2 Merge branch 'backport-1330-st-ino-win32-glib-2-62' into 'glib-2-62'
Backport !1330 “W32: Correctly set st_ino when doing private stat()” to glib-2-62

See merge request GNOME/glib!1331
2020-02-17 19:01:59 +00:00
Philip Withnall
88cb9fe514 libcharset: Drop a redundant environment variable
It was used for running tests when we built with autotools, but is no
longer used in the Meson build system. If we need something similar in
future, it should be done by adding internal API to override the
directory on a per-call basis, rather than loading a path from a shared
global table every time.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1919
2020-02-17 18:46:09 +00:00
Philip Withnall
9f0fc744c6 build: Rework path construction to reliably add prefix
There were a couple of custom paths which could end up being relative,
rather than absolute, due to not properly prefixing them with
`get_option('prefix')`.

The use of `join_paths()` here correctly drops all path components
before the final absolute path in the list of arguments. So if someone
configures GLib with an absolute path for `gio_module_dir`, that will be
used unprefixed; but if someone configures with a relative path, it will
be prefixed by `get_option('prefix)`.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1919
2020-02-17 18:46:09 +00:00
Philip Withnall
9f4af27412 Merge branch 'cherry-pick-2722620e' into 'glib-2-62'
Refactor g_socket_client_connect_async()

See merge request GNOME/glib!1365
2020-02-16 09:22:07 +00:00
Patrick Griffis
08677ed524 Refactor g_socket_client_connect_async()
This is a fairly large refactoring. The highlights are:

- Removing in-progress connections/addresses from GSocketClientAsyncConnectData:

  This caused issues where multiple ConnectionAttempt's would step over eachother
  and modify shared state causing bugs like accidentally bypassing a set proxy.

  Fixes #1871
  Fixes #1989
  Fixes #1902

- Cancelling address enumeration on error/completion

- Queuing successful TCP connections and doing application layer work serially:

  This is more in the spirit of Happy Eyeballs but it also greatly simplifies
  the flow of connection handling so fewer tasks are happening in parallel
  when they don't need to be.

  The behavior also should more closely match that of g_socket_client_connect().

- Better track the state of address enumeration:

  Previously we were over eager to treat enumeration finishing as an error.

  Fixes #1872
  See also #1982

- Add more detailed documentation and logging.

Closes #1995


(cherry picked from commit 2722620e32)
2020-02-16 08:57:30 +00:00
Simon McVittie
5a6f694184 tests: Cope with having CAP_DAC_OVERRIDE, even if not euid 0
Some CI platforms invoke these tests with euid != 0 but with
capabilities. Detect whether we have Linux CAP_DAC_OVERRIDE or other
OSs' equivalents, and skip tests that rely on DAC permissions being
denied if we do have that privilege.

(Cherry pick to 2.62: Fix one minor cherry-pick conflict.)

Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2027
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2028
2020-02-16 08:57:30 +00:00
Simon McVittie
58401555d8 tests: Don't assume that unprivileged uids are bound by RLIMIT_NPROC
Some CI platforms invoke tests as euid != 0, but with capabilities that
include CAP_SYS_RESOURCE and/or CAP_SYS_ADMIN. If we detect this,
we can't test what happens if our RLIMIT_NPROC is too low to create a
thread, because RLIMIT_NPROC is bypassed in these cases.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/2029
2020-02-16 08:57:30 +00:00
Sebastian Dröge
088cfde0ed Merge branch 'backport-1353-source-refs-glib-2-62' into 'glib-2-62'
Backport !1353 GMainContext source reference fixes to glib-2-62

See merge request GNOME/glib!1361
2020-02-12 16:59:49 +00:00
Sebastian Dröge
3c517fb0f7 GMainContext - Add tests for !1353 and related situations 2020-02-12 15:35:18 +00:00
Sebastian Dröge
8258bbfee1 GMainContext - Move mutex unlocking in destructor right before freeing the mutex
This does not have any behaviour changes but is cleaner. The mutex is
only unlocked now after all operations on the context are done and right
before freeing the mutex and the context itself.
2020-02-12 15:33:25 +00:00
Sebastian Dröge
c278612318 GMainContext - Fix memory leaks and memory corruption when freeing sources while freeing a context
Instead of destroying sources directly while freeing the context, and
potentially freeing them if this was the last reference to them, collect
new references of all sources in a separate list before and at the same
time invalidate their context so that they can't access it anymore. Only
once all sources have their context invalidated, destroy them while
still keeping a reference to them. Once all sources are destroyed we get
rid of the additional references and free them if nothing else keeps a
reference to them anymore.

This fixes a regression introduced by 26056558be in 2012.

The previous code that invalidated the context of each source and then
destroyed it before going to the next source without keeping an
additional reference caused memory leaks or memory corruption depending
on the order of the sources in the sources lists.

If a source was destroyed it might happen that this was the last
reference to this source, and it would then be freed. This would cause
the finalize function to be called, which might destroy and unref
another source and potentially free it. This other source would then
either
- go through the normal free logic and change the intern linked list
  between the sources, while other sources that are unreffed as part of
  the main context freeing would not. As such the list would be in an
  inconsistent state and we might dereference freed memory.
- go through the normal destroy and free logic but because the context
  pointer was already invalidated it would simply mark the source as
  destroyed without actually removing it from the context. This would
  then cause a memory leak because the reference owned by the context is
  not freed.

Fixes https://github.com/gtk-rs/glib/issues/583 while still keeping
https://bugzilla.gnome.org/show_bug.cgi?id=661767 fixes.
2020-02-12 15:33:25 +00:00
Sebastian Dröge
14ddde471f GMainContext - Fix GSource iterator if iteration can modify the list
We first have to ref the next source and then unref the previous one.
This might be the last reference to the previous source, and freeing the
previous source might unref and free the next one which would then leave
use with a dangling pointer here.

Fixes https://gitlab.gnome.org/GNOME/glib/issues/2031
2020-02-12 15:33:25 +00:00
Christian Kirbach
ec0983438a Update German translation 2020-02-09 14:01:58 +00:00
Sebastian Dröge
050f3a9a17 Merge branch 'backport-1351-suppression-fix-glib-2-62' into 'glib-2-62'
Backport !1351 “glib.supp: update g-threaded-resolver-getaddrinfo-config” to glib-2-62

See merge request GNOME/glib!1352
2020-02-06 11:02:53 +00:00
Guillaume Desmottes
b66c6f42b1 glib.supp: update g-threaded-resolver-getaddrinfo-config
This leak is now detected as 'definite' in newer version of Fedora,
see https://gitlab.freedesktop.org/gstreamer/gst-ci/merge_requests/226
2020-02-03 08:37:17 +00:00
Milo Casagrande
991e90e423 Update Italian translation 2020-01-31 12:24:52 +00:00
Руслан Ижбулатов
ff3c3be47d W32: Correctly set st_ino when doing private stat() 2020-01-20 10:54:17 +00:00
Daniel P. Berrange
4a72440efb gtimezone: fix parsing of Julian day in POSIX TZ format
The timezone(3) man page on Fedora 31 describes the start/end
field in the POSIX TZ format as follows:

[quote]
   The start field specifies when daylight  saving  time  goes
   into  effect and the end field specifies when the change is
   made back to standard time.  These fields may have the fol‐
   lowing formats:

   Jn     This  specifies  the Julian day with n between 1 and
          365.  Leap days are not counted.   In  this  format,
          February 29 can't be represented; February 28 is day
          59, and March 1 is always day 60.

   n      This specifies the  zero-based  Julian  day  with  n
          between  0  and 365.  February 29 is counted in leap
          years.

   Mm.w.d This specifies day d (0 <= d <= 6) of week w (1 <= w
          <=  5)  of  month  m  (1 <= m <= 12).  Week 1 is the
          first week in which day d occurs and week 5  is  the
          last week in which day d occurs.  Day 0 is a Sunday.
[/quote]

The GTimeZone code does not correctly parse the 'n' syntax,
treating it as having the range 1-365, the same as the 'Jn'
syntax. This is semantically broken as it makes it impossible
to represent the 366th day, which is the purpose of the 'n'
syntax.

There is a code comment saying this was done because the Linux
semantics are different from zOS and BSD. This is not correct,
as GLibC does indeed use the same 0-365 range as other operating
systems. It is believed that the original author was mislead by
a bug in old versions of the Linux libc timezone(3) man pages
which was fixed in

  commit 5a554f8e525faa98354c1b95bfe4aca7125a3657
  Author: Peter Schiffer <pschiffe@redhat.com>
  Date:   Sat Mar 24 16:08:10 2012 +1300

    tzset.3: Correct description for Julian 'n' date format

    The Julian 'n' date format counts atrting from 0, not 1.

    Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

Fixes: #1999

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2020-01-15 18:50:25 +00:00
Daniel P. Berrange
0439b0b648 gtimezone: fix inverted ignore_leap param parsing julian day
The callers of parse_tz_boundary inverted the value passed
for the ignore_leap parameter. Fortunately the method impl
also had an inverted test cancelling out the first bug.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2020-01-15 18:50:25 +00:00
Philip Withnall
df7e4bbda0 subprojects: Temporarily avoid using wrapdb while it’s down
This should fix our CI, which is currently failing on any system which
requires using the zlib subproject (typically VS systems) as wrapdb is
down. Work around that by pointing our wrap file at the underlying
github hosting instead.

See https://github.com/mesonbuild/meson/issues/6446#issuecomment-574241715

This can be reverted when wrapdb is working again.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-01-15 18:50:25 +00:00
Umarzuki Bin Mochlis Moktar
52c68388f5 Update Malay translation 2020-01-08 15:02:53 +00:00
Kukuh Syafaat
2db2658b71 Update Indonesian translation 2020-01-02 00:46:15 +00:00
Balázs Úr
26ba8242dc Update Hungarian translation 2019-12-30 18:13:23 +00:00
Daniel Mustieles
9f67778695 Updated Spanish translation 2019-12-30 12:47:44 +01:00