https://bugs.kde.org/show_bug.cgi?id=522307

--- Comment #7 from michaelk83 <[email protected]> ---
> 2-3. ... happy to extract and attach a relevant excerpt if you can
>  point me at what to grep for.

In the outgoing method calls, you have the `serial` number of each call. That
same number should appear in a `reply_serial` field of the corresponding reply
(or error). You can use that to find a few example replies. I expect they
should be the same each time, just want to see what they are.

For the incoming calls to KWallet, it's a little harder to say what we're
looking for... Generally speaking, you should be seeing
`destination=org.kde.kwalletd6` or `destination=org.kde.KWallet` for incoming
calls. We're trying to correlate any of those incoming calls to the outgoing
"ReadAlias" calls, or maybe to the start of the loop.

> 4. ... interestingly, 3 out of 5 samples show the main thread NOT in
>  defaultCollection()/ReadAlias, but instead in:
>      secret_item_create_sync()
>      secret_service_create_item_dbus_path_sync ()

This is probably because the `CreateItem` call is much slower than `ReadAlias`.
If they are paired, the CPU would be spending most of its time in `CreateItem`.
Gemini suggests the following `trace.gdb` script:

> set logging file gdb_trace.log
> set logging on
> set pagination off
> 
> break SecretServiceClient::defaultCollection
> commands 1
>   backtrace
>   continue
> end
> 
> run

Then run it with `gdb -x trace.gdb --args /path/to/app`.

It would be interesting to see the CreateItem replies as well. Since you
mentioned your `kdewallet_attributes.json` stays at a stable size, probably
those are failing. And I do want the debug symbols in the stack traces,
otherwise the most interesting parts are missing.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to