The on_portal_retrieve_secret() can connect a GCancellable, but it
doesn't disconnect from it (only when the cancellable is cancelled),
which means when the cancellable is cancelled later, when the GTask
is gone, the callback is called with already freed data.
As the GVariant serialization format does not record the original
endianness of integer values, we need to ensure that it doesn't change
between write and load.
As encrypt() is a standard POSIX function, its declaration had
conflict with our own. Let's be more verbose about naming of the
internal crypto functions.
Fixes#35.
When libgcrypt is available, libsecret links with it. When dynamic
linking is used, there is no problem: libsecret.so has a NEEDED
pointing to libgcrypt, so linking an application with -lsecret works
fine. However, when doing static linking, you must specify the entire
chain of libraries, otherwise you get unresolved symbols errors, such
as:
host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libsecret-1.a(libsecret_1_la-secret-session.o): In function `request_open_session_aes':
build/libsecret-0.18.3/libsecret/secret-session.c:99: undefined reference to `gcry_mpi_release'
build/libsecret-0.18.3/libsecret/secret-session.c:101: undefined reference to `gcry_mpi_aprint'
build/libsecret-0.18.3/libsecret/secret-session.c:107: undefined reference to `gcry_free'
In order to solve this, we simply need to indicate in the Libs.private
field of the .pc file that we depend on libgcrypt.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Retrieved from:
https://git.buildroot.net/buildroot/tree/package/libsecret/0001-libsecret.pc-add-Libs.private-field-for-libgcrypt.patch]
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This interface provides a separation between the
frontend (secret_password*) and the backend (SecretService). That
makes it easier to replace SecretService with a custom backend
implementation.
The condition checking g_task_is_valid was inverted, resulting in errors
being ignored.
Move the check to a g_return_val_if_fail to be in line with all other
uses of g_task_is_valid.
Fixes https://bugs.archlinux.org/task/63666
Given these functions take a hash table built from valid attributes,
there is no need to re-validate. This is also consistent with the
secret_service API.
This adds the secret_value_unref_to_password function that
unreferences and returns the stored secret in non-pageable memory.
This is supposed to be used with secret_password_lookup_binary*
functions.
This adds a set of functions that takes a SecretValue instead of a
text password when storing a secret. This is useful if the stored
password is not null-terminated.
This adds a set of functions that return a SecretValue instead of a
text password when looking up a secret. This is useful if the stored
password is not null-terminated.
This is a ground work for adding a local storage backend. As
SecretItem is derived from GDBusProxy, it cannot be simply exposed to
the application through the secret_password_search() if the item is
not backed by the DBus API. This adds an abstract interface
representing a read-only view of a secret item for that purpose.
In file included from /usr/include/libsecret-1/libsecret/secret.h:33,
from ../lib/sync/../ephy-sync-utils.h:24,
from ../lib/sync/ephy-history-manager.c:25:
/usr/include/libsecret-1/libsecret/secret-version.h:19: error: ignoring #pragma __once__ [-Werror=unknown-pragmas]
#pragma __once__
It should be #pragma once, not #pragma __once__.
But let's follow the other public headers here instead.
Added macros:
* SECRET_VERSION_MAJOR
* SECRET_VERSION_MINOR
* SECRET_VERSION_MICRO
* SECRET_CHECK_VERSION
These macros are widely defined in GLib based library. For example,
GLib, GTK, poppler GLib and so on define them.
These macros are useful to detect libsecret version on build type and
from GObject Introspection based bindings.
GSimpleAsyncResult is deprecated in favor of the simpler GTask, so use
that instead. This cuts down on the deprecation warnings.
I wanted to do both separately, but porting one without the other led to
some faulty casts from GSimpleAsyncResult to GTask (and vice versa).
Apart from having more developer-friendly messages if the assertions go
wrong, it also prevents the assertions not being run if
`G_DISABLE_ASSERT` is defined (e.g. for performance reasons).
Commit f36379af33 added the enumeration
GType for SecretCollectionFlags and SecretCollectionCreateFlags in the
introspection data, but by doing so it broke existing users of the
introspected API.
Additionally, the enumeration nicknames—which are used to generate the
enumeration value from the type name and the namespace—were wrong
before, and are wrong now. The idiomatic way to name enumeration members
is to use the uppercase, snake case version of the type name, and append
the value at the end:
SecretCollectionFlags → SECRET_COLLECTION_FLAGS_NONE
SecretCollectionCreateFlags → SECRET_COLLECTION_CREATE_FLAGS_NONE
If this practice is not followed, enumerations should use the
glib-mkenums trigraph and the `prefix` option; this tells glib-mkenums,
and the introspection parser after that, where to cut off the prefix and
which part of the enumeration value should be considered the nickname.
Thus, with `prefix=SECRET_COLLECTION` we can turn:
SECRET_COLLECTION_NONE
into:
Secret.CollectionFlags.NONE
which is the idiomatic form of an enumeration value.
Normally it shouldn't matter too much, but the GIR parser apparently
doesn't like it:
```
/home/niels/gnome/libsecret/libsecret/secret-schema.h:75: syntax error, unexpected ';' in ';' at ';'
/home/niels/gnome/libsecret/libsecret/secret-prompt.h:78: syntax error, unexpected ';' in ';' at ';'
/home/niels/gnome/libsecret/libsecret/secret-value.h:54: syntax error, unexpected ';' in ';' at ';'
/home/niels/gnome/libsecret/libsecret/secret-service.h:307: syntax error, unexpected ';' in ';' at ';'
/home/niels/gnome/libsecret/libsecret/secret-collection.h:176: syntax error, unexpected ';' in ';' at ';'
/home/niels/gnome/libsecret/libsecret/secret-item.h:194: syntax error, unexpected ';' in ';' at ';'
```
g_autoptr() is a macro that was defined in GLib 2.44 that allows for
basic auto-cleanup of variables. One way to add this kind of support
would be through the use of e.g. `G_DECLARE_DERIVABLE_TYPE()` for our
declarations, but this would consitute an ABI break (due to the
`...Private *` field in the public structs). Instead, we can use
`G_DEFINE_AUTOPTR_CLEANUP_FUNC` to manually declare this.
This commit also bumps the minimally required GLib version to 2.44
Initialize the schema_name so that NULL is returned when the schema name
is absent, instead of an uninitialized memory. Mark return value as
nullable to indicate this for introspection and documentation.
Previously there were no functions in the simple API that return the
matched attributes other than the secret value, while there were needs
for augumenting user input with additional information (such as
completing web forms).
This adds a set of functions which wrap secret_service_search*. Note
that the return value is a list of GHashTable not of SecretItem,
because SecretItem is a subclass of GDBusProxy, which we don't want to
expose from the simple API.
Fixes#16
The SECRET_SCHEMA_* extern structs are not introspectable; add a new
accessor function which takes an enum and returns a struct, which is
introspectable.
Mark the old extern structs as (skip), but don’t deprecate them because
they’re still useful from C (if unconventional).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=697681
If the gnome-keyring D-Bus service is not responding, we wind up freeing
the SearchClosure in an error path without ever creating a SecretService
object. Guard against this.
https://bugzilla.gnome.org/show_bug.cgi?id=787391
Without this the generated C code compiles without the correct header (warnings
are disabled so this is not obvious). This was causing the test to crash on
Ubuntu (exact cause not diagnosed).
https://bugzilla.gnome.org/show_bug.cgi?id=767002
g_atomic_int_add (&schema->refs, -1); will return the value of 'refs'
_before_ adding -1 to it, so checking this value for 0 to see if the
refcount dropped to 0 after adding -1 is not going to work and will
cause a leak.
Using g_atomic_int_dec_and_test() fixes this problem as this will return
TRUE when the value drops to 0 after being decremented.
https://bugzilla.gnome.org/show_bug.cgi?id=756766
The memory allocated for the SecretSync instance itself was not freed. This fixes:
==7106== 24 bytes in 1 blocks are definitely lost in loss record 855 of 1,629
==7106== at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7106== by 0x600303F: g_malloc0 (gmem.c:124)
==7106== by 0x6003322: g_malloc0_n (gmem.c:354)
==7106== by 0x4E6979D: _secret_sync_new (secret-util.c:441)
==7106== by 0x4E65D11: secret_service_read_alias_dbus_path_sync (secret-paths.c:2334)
==7106== by 0x4E4E09E: secret_collection_for_alias_sync (secret-collection.c:2221)
==7106== by 0x40270E: test_for_alias_sync (test-collection.c:187)
==7106== by 0x60258FA: test_case_run (gtestutils.c:2158)
==7106== by 0x6025CBB: g_test_run_suite_internal (gtestutils.c:2241)
==7106== by 0x6025D64: g_test_run_suite_internal (gtestutils.c:2253)
==7106== by 0x6025F7B: g_test_run_suite (gtestutils.c:2328)
==7106== by 0x6024C1C: g_test_run (gtestutils.c:1596)
==7106== by 0x4E7CA3B: egg_tests_run_with_loop (egg-testing.c:167)
==7106== by 0x406948: main (test-collection.c:1033)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==17724== 48 bytes in 1 blocks are definitely lost in loss record 1,135 of 1,698
==17724== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17724== by 0x6002FCC: g_malloc (gmem.c:94)
==17724== by 0x60032AE: g_malloc_n (gmem.c:330)
==17724== by 0x601DBF0: g_strdup (gstrfuncs.c:363)
==17724== by 0x4E650B5: on_create_item_called (secret-paths.c:1990)
==17724== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==17724== by 0x5A33575: g_task_return (gtask.c:1162)
==17724== by 0x5A33E76: g_task_return_pointer (gtask.c:1537)
==17724== by 0x5A9BB7D: g_dbus_connection_call_done (gdbusconnection.c:5704)
==17724== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==17724== by 0x5A334B6: complete_in_idle_cb (gtask.c:1118)
==17724== by 0x5FFD3D0: g_idle_dispatch (gmain.c:5441)
==17724== by 0x5FFAA18: g_main_dispatch (gmain.c:3154)
==17724== by 0x5FFB85C: g_main_context_dispatch (gmain.c:3769)
==17724== by 0x5FFBA40: g_main_context_iterate (gmain.c:3840)
==17724== by 0x5FFBE66: g_main_loop_run (gmain.c:4034)
==17724== by 0x4E55FF7: secret_service_store_sync (secret-methods.c:1281)
==17724== by 0x404AC8: test_store_sync (test-methods.c:736)
==17724== by 0x60258FA: test_case_run (gtestutils.c:2158)
==17724== by 0x6025CBB: g_test_run_suite_internal (gtestutils.c:2241)
==17724== by 0x6025D64: g_test_run_suite_internal (gtestutils.c:2253)
==17724== by 0x6025F7B: g_test_run_suite (gtestutils.c:2328)
==17724== by 0x6024C1C: g_test_run (gtestutils.c:1596)
==17724== by 0x4E7CA68: egg_tests_run_with_loop (egg-testing.c:167)
==17724== by 0x406190: main (test-methods.c:998)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==2111== 45 bytes in 1 blocks are definitely lost in loss record 1,180 of 1,795
==2111== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2111== by 0x6002FCC: g_malloc (gmem.c:94)
==2111== by 0x60032AE: g_malloc_n (gmem.c:330)
==2111== by 0x601DBF0: g_strdup (gstrfuncs.c:363)
==2111== by 0x603C073: g_variant_dup_string (gvariant.c:1503)
==2111== by 0x4E644D5: on_create_collection_prompt (secret-paths.c:1682)
==2111== by 0x5A1CB66: g_simple_async_result_complete (gsimpleasyncresult.c:801)
==2111== by 0x4E5C12F: on_real_prompt_completed (secret-service.c:322)
==2111== by 0x5A1CB66: g_simple_async_result_complete (gsimpleasyncresult.c:801)
==2111== by 0x4E5A6A1: perform_prompt_complete (secret-prompt.c:288)
==2111== by 0x4E5A7B5: on_prompt_completed (secret-prompt.c:314)
==2111== by 0x5A97B7B: emit_signal_instance_in_idle_cb (gdbusconnection.c:3701)
==2111== by 0x5FFD3D0: g_idle_dispatch (gmain.c:5441)
==2111== by 0x5FFAA18: g_main_dispatch (gmain.c:3154)
==2111== by 0x5FFB85C: g_main_context_dispatch (gmain.c:3769)
==2111== by 0x5FFBA40: g_main_context_iterate (gmain.c:3840)
==2111== by 0x5FFBE66: g_main_loop_run (gmain.c:4034)
==2111== by 0x4E7C9E1: loop_wait_until (egg-testing.c:151)
==2111== by 0x4E7C859: egg_test_wait_until (egg-testing.c:105)
==2111== by 0x4032ED: test_create_async (test-collection.c:328)
==2111== by 0x60258FA: test_case_run (gtestutils.c:2158)
==2111== by 0x6025CBB: g_test_run_suite_internal (gtestutils.c:2241)
==2111== by 0x6025D64: g_test_run_suite_internal (gtestutils.c:2253)
==2111== by 0x6025F7B: g_test_run_suite (gtestutils.c:2328)
==2111== by 0x6024C1C: g_test_run (gtestutils.c:1596)
==2111== by 0x4E7CA3B: egg_tests_run_with_loop (egg-testing.c:167)
==2111== by 0x406948: main (test-collection.c:1033)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==16832== 6 bytes in 1 blocks are definitely lost in loss record 8 of 1,184
==16832== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16832== by 0x36E564F679: g_malloc (gmem.c:97)
==16832== by 0x36E56688AE: g_strdup (gstrfuncs.c:356)
==16832== by 0x4C2B242: secret_collection_get_label (secret-collection.c:1835)
==16832== by 0x40313D: test_create_sync (test-collection.c:305)
==16832== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16832== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16832== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16832== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16832== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16832== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16832== by 0x4068B0: main (test-collection.c:1028)
==16832==-
==16832== 6 bytes in 1 blocks are definitely lost in loss record 9 of 1,184
==16832== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16832== by 0x36E564F679: g_malloc (gmem.c:97)
==16832== by 0x36E56688AE: g_strdup (gstrfuncs.c:356)
==16832== by 0x4C2B242: secret_collection_get_label (secret-collection.c:1835)
==16832== by 0x40337C: test_create_async (test-collection.c:333)
==16832== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16832== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16832== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16832== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16832== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16832== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16832== by 0x4068B0: main (test-collection.c:1028)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes (among others):
==16832== 95 (16 direct, 79 indirect) bytes in 1 blocks are definitely lost in loss record 927 of 1,184
==16832== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16832== by 0x36E564F679: g_malloc (gmem.c:97)
==16832== by 0x36E5666CD2: g_slice_alloc (gslice.c:1007)
==16832== by 0x36E563522B: g_error_new_valist (gerror.c:386)
==16832== by 0x36E563560A: g_set_error (gerror.c:560)
==16832== by 0x4C27FB4: secret_collection_initable_init (secret-collection.c:543)
==16832== by 0x36E6E5D83E: g_initable_new_valist (ginitable.c:228)
==16832== by 0x36E6E5D8F5: g_initable_new (ginitable.c:146)
==16832== by 0x4C3E1E3: secret_collection_new_for_dbus_path_sync (secret-paths.c:158)
==16832== by 0x404733: test_delete_sync (test-collection.c:623)
==16832== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16832== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16832== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16832== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16832== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16832== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16832== by 0x4068B0: main (test-collection.c:1028)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==16832== 7 bytes in 1 blocks are definitely lost in loss record 10 of 1,184
==16832== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16832== by 0x36E564F679: g_malloc (gmem.c:97)
==16832== by 0x36E56688AE: g_strdup (gstrfuncs.c:356)
==16832== by 0x36E6EDEB98: g_dbus_proxy_get_name_owner (gdbusproxy.c:2372)
==16832== by 0x4C38B64: secret_prompt_perform (secret-prompt.c:468)
==16832== by 0x4C39F4C: secret_service_real_prompt_async (secret-service.c:339)
==16832== by 0x4C3D126: secret_service_prompt (secret-service.c:1711)
==16832== by 0x4C42182: on_create_collection_called (secret-paths.c:1706)
==16832== by 0x36E6E74BA6: g_simple_async_result_complete (gsimpleasyncresult.c:763)
==16832== by 0x36E6ED1921: g_dbus_connection_call_done (gdbusconnection.c:5508)
==16832== by 0x36E6E74BA6: g_simple_async_result_complete (gsimpleasyncresult.c:763)
==16832== by 0x36E6E74C08: complete_in_idle_cb (gsimpleasyncresult.c:775)
==16832== by 0x36E5649A89: g_main_dispatch (gmain.c:3122)
==16832== by 0x36E5649A89: g_main_context_dispatch (gmain.c:3737)
==16832== by 0x36E5649E1F: g_main_context_iterate.isra.29 (gmain.c:3808)
==16832== by 0x36E564A141: g_main_loop_run (gmain.c:4002)
==16832== by 0x4C427F1: secret_service_create_collection_dbus_path_sync (secret-paths.c:1908)
==16832== by 0x4C299F9: secret_collection_create_sync (secret-collection.c:1211)
==16832== by 0x403084: test_create_sync (test-collection.c:299)
==16832== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16832== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16832== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16832== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16832== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16832== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16832== by 0x4068B0: main (test-collection.c:1028)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==22678== 48 bytes in 1 blocks are definitely lost in loss record 1,045 of 1,560
==22678== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==22678== by 0x6002FCC: g_malloc (gmem.c:94)
==22678== by 0x60032AE: g_malloc_n (gmem.c:330)
==22678== by 0x601DBF0: g_strdup (gstrfuncs.c:363)
==22678== by 0x4E6508B: on_create_item_called (secret-paths.c:1991)
==22678== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==22678== by 0x5A33575: g_task_return (gtask.c:1162)
==22678== by 0x5A33E76: g_task_return_pointer (gtask.c:1537)
==22678== by 0x5A9BB7D: g_dbus_connection_call_done (gdbusconnection.c:5704)
==22678== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==22678== by 0x5A334B6: complete_in_idle_cb (gtask.c:1118)
==22678== by 0x5FFD3D0: g_idle_dispatch (gmain.c:5441)
==22678== by 0x5FFAA18: g_main_dispatch (gmain.c:3154)
==22678== by 0x5FFB85C: g_main_context_dispatch (gmain.c:3769)
==22678== by 0x5FFBA40: g_main_context_iterate (gmain.c:3840)
==22678== by 0x5FFBE66: g_main_loop_run (gmain.c:4034)
==22678== by 0x4E7C9E4: loop_wait_until (egg-testing.c:151)
==22678== by 0x4E7C85C: egg_test_wait_until (egg-testing.c:105)
==22678== by 0x402D22: test_create_async (test-item.c:245)
==22678== by 0x60258FA: test_case_run (gtestutils.c:2158)
==22678== by 0x6025CBB: g_test_run_suite_internal (gtestutils.c:2241)
==22678== by 0x6025D64: g_test_run_suite_internal (gtestutils.c:2253)
==22678== by 0x6025F7B: g_test_run_suite (gtestutils.c:2328)
==22678== by 0x6024C1C: g_test_run (gtestutils.c:1596)
==22678== by 0x4E7CA3E: egg_tests_run_with_loop (egg-testing.c:167)
==22678== by 0x406B52: main (test-item.c:887)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==20768== 67 (40 direct, 27 indirect) bytes in 1 blocks are definitely lost in loss record 1,133 of 1,588
==20768== at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20768== by 0x6002FCC: g_malloc (gmem.c:94)
==20768== by 0x601B523: g_slice_alloc (gslice.c:1007)
==20768== by 0x601B563: g_slice_alloc0 (gslice.c:1032)
==20768== by 0x4E5FB64: secret_value_new_full (secret-value.c:140)
==20768== by 0x4E67B63: service_decode_aes_secret (secret-session.c:457)
==20768== by 0x4E67D6B: _secret_session_decode_secret (secret-session.c:513)
==20768== by 0x4E50A61: on_item_load_secret (secret-item.c:1157)
==20768== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==20768== by 0x5A33575: g_task_return (gtask.c:1162)
==20768== by 0x5A33E76: g_task_return_pointer (gtask.c:1537)
==20768== by 0x5AAC7E6: reply_cb (gdbusproxy.c:2579)
==20768== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==20768== by 0x5A33575: g_task_return (gtask.c:1162)
==20768== by 0x5A33E76: g_task_return_pointer (gtask.c:1537)
==20768== by 0x5A9BB7D: g_dbus_connection_call_done (gdbusconnection.c:5704)
==20768== by 0x5A3346D: g_task_return_now (gtask.c:1104)
==20768== by 0x5A334B6: complete_in_idle_cb (gtask.c:1118)
==20768== by 0x5FFD3D0: g_idle_dispatch (gmain.c:5441)
==20768== by 0x5FFAA18: g_main_dispatch (gmain.c:3154)
==20768== by 0x5FFB85C: g_main_context_dispatch (gmain.c:3769)
==20768== by 0x5FFBA40: g_main_context_iterate (gmain.c:3840)
==20768== by 0x5FFBE66: g_main_loop_run (gmain.c:4034)
==20768== by 0x4E510DA: secret_item_load_secret_sync (secret-item.c:1311)
==20768== by 0x405238: test_load_secret_sync (test-item.c:592)
==20768== by 0x60258FA: test_case_run (gtestutils.c:2158)
==20768== by 0x6025CBB: g_test_run_suite_internal (gtestutils.c:2241)
==20768== by 0x6025D64: g_test_run_suite_internal (gtestutils.c:2253)
==20768== by 0x6025F7B: g_test_run_suite (gtestutils.c:2328)
==20768== by 0x6024C1C: g_test_run (gtestutils.c:1596)
==20768== by 0x4E7CA25: egg_tests_run_with_loop (egg-testing.c:167)
==20768== by 0x406B52: main (test-item.c:887)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==16901== 7 bytes in 1 blocks are definitely lost in loss record 9 of 1,154
==16901== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16901== by 0x36E564F679: g_malloc (gmem.c:97)
==16901== by 0x36E56688AE: g_strdup (gstrfuncs.c:356)
==16901== by 0x4C3098F: secret_item_get_label (secret-item.c:1922)
==16901== by 0x402A65: test_create_sync (test-item.c:203)
==16901== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16901== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16901== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16901== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16901== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16901== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16901== by 0x406AAE: main (test-item.c:880)
==16901==-
==16901== 7 bytes in 1 blocks are definitely lost in loss record 10 of 1,154
==16901== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16901== by 0x36E564F679: g_malloc (gmem.c:97)
==16901== by 0x36E56688AE: g_strdup (gstrfuncs.c:356)
==16901== by 0x4C3098F: secret_item_get_label (secret-item.c:1922)
==16901== by 0x402DB6: test_create_async (test-item.c:249)
==16901== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16901== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16901== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16901== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16901== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16901== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16901== by 0x406AAE: main (test-item.c:880)
==16901==-
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==16901== 248 (88 direct, 160 indirect) bytes in 1 blocks are definitely lost in loss record 1,108 of 1,154
==16901== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16901== by 0x36E564F679: g_malloc (gmem.c:97)
==16901== by 0x36E5666CD2: g_slice_alloc (gslice.c:1007)
==16901== by 0x36E563860D: g_hash_table_new_full (ghash.c:711)
==16901== by 0x4047B2: test_set_attributes_async (test-item.c:493)
==16901== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16901== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16901== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16901== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16901== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16901== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16901== by 0x406AAE: main (test-item.c:880)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
This fixes:
==16901== 94 (16 direct, 78 indirect) bytes in 1 blocks are definitely lost in loss record 901 of 1,154
==16901== at 0x4A06C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16901== by 0x36E564F679: g_malloc (gmem.c:97)
==16901== by 0x36E5666CD2: g_slice_alloc (gslice.c:1007)
==16901== by 0x36E563522B: g_error_new_valist (gerror.c:386)
==16901== by 0x36E563560A: g_set_error (gerror.c:560)
==16901== by 0x4C2CFB2: secret_item_initable_init (secret-item.c:480)
==16901== by 0x36E6E5D83E: g_initable_new_valist (ginitable.c:228)
==16901== by 0x36E6E5D8F5: g_initable_new (ginitable.c:146)
==16901== by 0x4C3E711: secret_item_new_for_dbus_path_sync (secret-paths.c:286)
==16901== by 0x402506: test_new_sync_noexist (test-item.c:121)
==16901== by 0x36E566FB92: test_case_run (gtestutils.c:2124)
==16901== by 0x36E566FB92: g_test_run_suite_internal (gtestutils.c:2185)
==16901== by 0x36E566FD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16901== by 0x36E56700DA: g_test_run_suite (gtestutils.c:2249)
==16901== by 0x36E5670110: g_test_run (gtestutils.c:1553)
==16901== by 0x4C5A0EA: egg_tests_run_with_loop (egg-testing.c:167)
==16901== by 0x406AAE: main (test-item.c:880)
https://bugzilla.gnome.org/show_bug.cgi?id=756766
