search

status-im / status-desktop

Status Desktop client made in Nim & QML
https://status.app
Mozilla Public License 2.0
298 stars 79 forks source link

The app doesn't die when closing with the X (or right click - close on Mac) #15939

Closed jrainville closed 3 months ago

jrainville commented 3 months ago

Bug Report

Description

If you close the app with the X button (and most likely with any other means other than CTRL-C), it doesn't die (stays "logging out...")

Steps to reproduce

  1. Open the app in a console
  2. Login
  3. Make the computer go to sleep
  4. Come back from sleep
  5. Close the app with the X
  6. See the console

Expected behavior

The app dies in less than 5 seconds

Actual behavior

The app doesn't die even after 2 minutes

Additional Information

jrainville commented 3 months ago

I tried with a very basic account that only has one community (1 member) and it closes fine.

So then I retried my main account on the latest release branch.. and it doesn't reproduce. Alright then. I'll close

jrainville commented 3 months ago

I was able to reproduce and I know the repro step now: It happens after coming back from sleep! I'll update the description.

@igor-sirotin can you check if you can repro on Mac?

igor-sirotin commented 3 months ago

@jrainville seem to be working fine for me on Mac 🙁

igor-sirotin commented 3 months ago

@jrainville can you please try to attach debugger before closing the app? (probably after waking up from sleep, but before closing app)

igor-sirotin commented 3 months ago

I think I accidentally faced the same behaviour.

image image

Attached debugger, it didn't really help. I noticed that the thread 1 is CrBrowserMain, which is weird.

After some point the CPU usage came down:

image

MacOS hang report

After killing the app I saved 90k lines MacOS report. Some interesting notes from it:

Heaviest stack for the main thread of the target process:
  79  runtime.asmcgocall.abi0 + 200 (libstatus.dylib + 485480) [0x10d7ba868]
  79  <patched truncated backtrace>
  79  runtime.pthread_cond_wait_trampoline.abi0 + 24 (libstatus.dylib + 491352) [0x10d7bbf58]
  79  __psynch_cvwait + 8 (libsystem_kernel.dylib + 18924) [0x19fd7d9ec]
 *79  psynch_cvcontinue + 0 (com.apple.kec.pthread + 18232) [0xfffffe000b834a58]
  Thread 0xdf9dec    DispatchQueue "com.apple.main-thread"(1)    Thread name "CrBrowserMain"    79 samples (1-79)    priority 46 (base 46)
  <thread QoS user interactive (requested user interactive), process unclamped, process received importance donation from WindowServer [423], IO tier 0>
  79  runtime.asmcgocall.abi0 + 200 (libstatus.dylib + 485480) [0x10d7ba868] 1-79
    79  <patched truncated backtrace> 1-79
      79  runtime.pthread_cond_wait_trampoline.abi0 + 24 (libstatus.dylib + 491352) [0x10d7bbf58] 1-79
        79  __psynch_cvwait + 8 (libsystem_kernel.dylib + 18924) [0x19fd7d9ec] 1-79
         *49  psynch_cvcontinue + 0 (com.apple.kec.pthread + 18232) [0xfffffe000b834a58] 1-49
  <2000ms gap with no samples>
         *30  psynch_cvcontinue + 0 (com.apple.kec.pthread + 18232) [0xfffffe000b834a58] 50-79
jrainville commented 3 months ago

I managed to close the app correctly after sleep, but in that case, I closed very fast after waking up, so I'm guessing the store node fetch didn't start yet

jrainville commented 3 months ago

On the latest release branch, I can't reproduce so far with a pretty small account.

I'll try with my main account to see if it's something about having some sort of wallet account or community

jrainville commented 3 months ago

hmm, even with my main account, I can no longer reproduce 🤔

I'm fairly sure I could reproduce in dev, so it shouldn't be about that. I'll give it a try with a recent release build just in case

jrainville commented 3 months ago

I still can't reproduce from just going to sleep, waking up and closing.

So I guess to reproduce, I need to wait longer before closing. Maybe some sort of timer needs to trigger first. Because I did try leaving it sleeping for 30 minutes when going to sleep and it didn't reproduce.

jrainville commented 3 months ago

I let it run in dev for 40 minutes after a sleep and then closed it and it closed without issue.

it's very weird, when I don't want to reproduce the issue, it reproduces, but when I try to reproduce, it works fine 😩

jrainville commented 3 months ago

I finally had a reproduction on a dev build with my main account. This time, the sleep was for the whole night and I ran it for one hour and a half before trying to close it.

Here are the interesting things in the logs:

Here are the full logs: geth.log

Now I'll try to compare with a successful app close

jrainville commented 3 months ago

Ok, on a successful close, the amount of logs is way lower. We still have some of the same logs as before, for example Error sending messages. and Failed to persisten epoch.

However, I see in the end Epoch processing stopped, there is no Failed to get pending transactions, no Evicting item from balance/nonce cache, and I don't see messages for next store hash query after the logout

Geth log of a success: geth.log

jrainville commented 3 months ago

I have another repro, this time on the release app.

I don't see messages for next store hash query, so that was probably a red herring.

Some logs are still there though, like Failed to get pending transactions. I think I'll investigate if that pending transaction loop fails to close itself

geth.log

jrainville commented 3 months ago

Another repro. Still the same logs that happen again, ie Failed to get pending transactions.

This one was there again too Evicting item from balance/nonce cache

geth.log

igor-sirotin commented 3 months ago

I noticed that sometimes the app freezes at minimizing. But I'm able to kill it simply with Ctrl+C.

^CTraceback (most recent call last)
/Users/igorsirotin/Repositories/Status/status-desktop/src/nim_status_client.nim(254) nim_status_client
/Users/igorsirotin/Repositories/Status/status-desktop/src/nim_status_client.nim(251) mainProc
/Users/igorsirotin/Repositories/Status/status-desktop/vendor/nimqml/src/nimqml/private/qguiapplication.nim(29) exec
/Users/igorsirotin/Repositories/Status/status-desktop/vendor/nimqml/src/nimqml/private/qobject.nim(52) qobjectCallback
/Users/igorsirotin/Repositories/Status/status-desktop/vendor/nimqml/src/nimqml/private/qobject.nim(37) onSlotCalled
/Users/igorsirotin/Repositories/Status/status-desktop/vendor/nimbus-build-system/vendor/Nim/lib/core/macros.nim(591) onSlotCalled
/Users/igorsirotin/Repositories/Status/status-desktop/src/app/modules/main/view.nim(329) windowActivated
/Users/igorsirotin/Repositories/Status/status-desktop/src/app/modules/main/io_interface.nim(382) windowActivated
/Users/igorsirotin/Repositories/Status/status-desktop/src/app/modules/main/module.nim(1626) windowActivated
/Users/igorsirotin/Repositories/Status/status-desktop/src/app/modules/main/controller.nim(584) slowdownArchivesImport
/Users/igorsirotin/Repositories/Status/status-desktop/src/app_service/service/community/service.nim(1926) slowdownArchivesImport
/Users/igorsirotin/Repositories/Status/status-desktop/src/backend/communities.nim(467) slowdownArchivesImport
/Users/igorsirotin/Repositories/Status/status-desktop/src/backend/core.nim(71) callPrivateRPC
/Users/igorsirotin/Repositories/Status/status-desktop/src/backend/core.nim(28) makePrivateRpcCall
/Users/igorsirotin/Repositories/Status/status-desktop/vendor/nim-status-go/status_go.nim(75) callPrivateRPC
SIGINT: Interrupted by Ctrl-C.
make: *** [run-macos] Interrupt: 2
jrainville commented 3 months ago

turns out the main issue was with a waitGroup in the waku package that didn't call its Done and the Telemetry service that didn't use the context