[SyncEvolution] Syncing to Memotoo w SyncEvolution post-Fedora 37 upgrade (fwd)
Max Pyziur
pyz at brama.com
Tue Feb 21 12:17:50 UTC 2023
On Tue, 21 Feb 2023, Patrick Ohly wrote:
> Max Pyziur <pyz at brama.com> writes:
>> On Sun, 19 Feb 2023, Patrick Ohly wrote:
>> Here is the command that I run in a separate shell:
>> $ syncevolution --run --sync refresh-from-local memotoo
>>
>>> The relevant output is the one from valgrind.
>>
>> This is the output that I receive:
>> pyz at pegasus ~/projects/HomeComputers/Pegasus> valgrind
>> /usr/libexec/syncevo-dbus-server
>> ==6181== Memcheck, a memory error detector
>> ==6181== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
>> ==6181== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright
>> info
>> ==6181== Command: /usr/libexec/syncevo-dbus-server
>> ==6181==
>> --6181-- WARNING: unhandled amd64-linux syscall: 434
>> --6181-- You may be able to write your own handler.
>> --6181-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>> --6181-- Nevertheless we consider this a bug. Please report
>> --6181-- it at http://valgrind.org/support/bug_reports.html.
>
> And that's all? It doesn't crash anymore?
It crashes.
> To be clear, you need to run `syncevolution --run --sync
> refresh-from-local memotoo` while valgrind is in control of
> syncevo-dbus-server.
I did; it was in the reply that I sent, please see above.
I'll repeat the steps as I know them; I am also expanding the 'valgrind'
command.
#1
pyz at pegasus ~> ps waux | grep sync
pyz 5511 0.0 0.3 527508 28416 ? Ssl 07:09 0:00
/usr/libexec/syncevo-dbus-server
pyz 5756 0.0 0.0 222156 2124 pts/2 R+ 07:12 0:00 grep
--color=auto sync
pyz at pegasus ~> killall syncevo-dbus-server
#2
Start valgrind thusly:
pyz at pegasus ~> valgrind --leak-check=full /usr/libexec/syncevo-dbus-server
#3
Run in a separate window and receive the following output:
pyz at pegasus ~> syncevolution --run --sync refresh-from-local memotoo
[INFO] memo: inactive
[INFO] todo: inactive
[ERROR syncevo-dbus-server] child process quit because of signal 11
[ERROR] The connection is closed
pyz at pegasus ~>
#4
I receive the following output from the valgrind command:
pyz at pegasus ~> valgrind --leak-check=full /usr/libexec/syncevo-dbus-server
==5779== Memcheck, a memory error detector
==5779== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==5779== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright
info
==5779== Command: /usr/libexec/syncevo-dbus-server
==5779==
[ERROR syncevo-dbus-server] could not obtain D-Bus name - already running?
==5779==
==5779== HEAP SUMMARY:
==5779== in use at exit: 316,386 bytes in 2,924 blocks
==5779== total heap usage: 27,681 allocs, 24,757 frees, 2,527,967 bytes
allocated
==5779==
==5779== 400 bytes in 1 blocks are possibly lost in loss record 2,074 of
2,119
==5779== at 0x4848464: calloc (vg_replace_malloc.c:1340)
==5779== by 0x4011412: UnknownInlinedFun (rtld-malloc.h:44)
==5779== by 0x4011412: allocate_dtv (dl-tls.c:375)
==5779== by 0x4011E11: _dl_allocate_tls (dl-tls.c:634)
==5779== by 0x5213CFE: allocate_stack (allocatestack.c:423)
==5779== by 0x5213CFE: pthread_create@@GLIBC_2.34
(pthread_create.c:650)
==5779== by 0x4E77B60: UnknownInlinedFun (gthread-posix.c:1324)
==5779== by 0x4E77B60: g_thread_new_internal (gthread.c:936)
==5779== by 0x4E77D72: g_thread_new (gthread.c:888)
==5779== by 0x4E4B786: g_get_worker_context (gmain.c:6441)
==5779== by 0x4C64D84: UnknownInlinedFun (gtask.c:2208)
==5779== by 0x4C64D84: g_task_get_type_once (gtask.c:616)
==5779== by 0x4C64E34: g_task_get_type (gtask.c:616)
==5779== by 0x4CD1298: UnknownInlinedFun (gdbusprivate.c:255)
==5779== by 0x4CD1298: _g_dbus_initialize.part.0 (gdbusprivate.c:1980)
==5779== by 0x4CB4D98: UnknownInlinedFun (gdbusprivate.c:1950)
==5779== by 0x4CB4D98: UnknownInlinedFun (gdbusprivate.c:1912)
==5779== by 0x4CB4D98: g_dbus_address_get_for_bus_sync
(gdbusaddress.c:1299)
==5779== by 0x4896602: GDBusCXX::dbus_get_bus_connection(char const*,
char const*, bool, GDBusCXX::DBusErrorCXX*) (gdbus-cxx-bridge.cpp:174)
==5779==
==5779== 400 bytes in 1 blocks are possibly lost in loss record 2,075 of
2,119
==5779== at 0x4848464: calloc (vg_replace_malloc.c:1340)
==5779== by 0x4011412: UnknownInlinedFun (rtld-malloc.h:44)
==5779== by 0x4011412: allocate_dtv (dl-tls.c:375)
==5779== by 0x4011E11: _dl_allocate_tls (dl-tls.c:634)
==5779== by 0x5213CFE: allocate_stack (allocatestack.c:423)
==5779== by 0x5213CFE: pthread_create@@GLIBC_2.34
(pthread_create.c:650)
==5779== by 0x4E77B60: UnknownInlinedFun (gthread-posix.c:1324)
==5779== by 0x4E77B60: g_thread_new_internal (gthread.c:936)
==5779== by 0x4E77D72: g_thread_new (gthread.c:888)
==5779== by 0x4CBB046: UnknownInlinedFun (gdbusprivate.c:309)
==5779== by 0x4CBB046: UnknownInlinedFun (gdbusprivate.c:1694)
==5779== by 0x4CBB046: initable_init (gdbusconnection.c:2607)
==5779== by 0x4C306C7: g_initable_new_valist (ginitable.c:250)
==5779== by 0x4C307BC: g_initable_new (ginitable.c:164)
==5779== by 0x4CBCF63: g_dbus_connection_new_for_address_sync
(gdbusconnection.c:2963)
==5779== by 0x4896622: GDBusCXX::dbus_get_bus_connection(char const*,
char const*, bool, GDBusCXX::DBusErrorCXX*) (gdbus-cxx-bridge.cpp:183)
==5779== by 0x1618B9: main (main.cpp:221)
==5779==
==5779== LEAK SUMMARY:
==5779== definitely lost: 0 bytes in 0 blocks
==5779== indirectly lost: 0 bytes in 0 blocks
==5779== possibly lost: 800 bytes in 2 blocks
==5779== still reachable: 294,226 bytes in 2,712 blocks
==5779== suppressed: 0 bytes in 0 blocks
==5779== Reachable blocks (those to which a pointer was found) are not
shown.
==5779== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5779==
==5779== For lists of detected and suppressed errors, rerun with: -s
==5779== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
pyz at pegasus ~>
fyi,
M
More information about the SyncEvolution
mailing list