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
libcrypt no longer supports setting our own threading callbacks,
and is thread-safe if we call gcry_check_version() before creating
threads.
Unfortunately we can't guarantee that we call gcry_check_version()
early enough, we try our best. Most of the callers of libsecret either
don't use libgcrypt, or also initialize it appropriately themselves.
Bump libgcrypt dependency to 1.4.5+, and have earlier versions use
the native pthread implementation of locking.
