App crashes when tapping Disconnect button

[ilok67]

When the user taps the Disconnect button, the app crashes. This happens because MainActivity.onStop callback sends ACTION_STOP via startService() and then immediately calls stopService() on the same service, creating a race condition with the teardown thread inside MhrvVpnService.

Root cause:

In MainActivity, the onStop lambda does:

onStop = {
    val stopAction = Intent(this, MhrvVpnService::class.java)
        .setAction(MhrvVpnService.ACTION_STOP)
    startService(stopAction)
    stopService(Intent(this, MhrvVpnService::class.java))  // ← crashes here
}

Meanwhile in MhrvVpnService.onStartCommand, the ACTION_STOP branch spawns a background thread to run teardown() and then calls stopSelf():

ACTION_STOP -> {
    try { stopForeground(STOP_FOREGROUND_REMOVE) } catch ...
    Thread({
        teardown()
        stopSelf()
    }, "mhrv-teardown").start()
    START_NOT_STICKY
}

The problem:

1. startService(stopAction) delivers ACTION_STOP → spawns "mhrv-teardown" thread → thread starts teardown() (which includes Native.stopProxy(handle) and can take several seconds).
2. stopService() is called immediately after on the same service. This triggers onDestroy() while the teardown thread is still running. Two threads now race through service lifecycle — the background thread calling stopSelf() on a service that stopService() is already destroying.
3. Depending on timing, this can cause:
   · stopSelf() crashing because the service is already being destroyed by stopService()
   · onDestroy() racing with the teardown thread mid-cleanup
   · The service process dying while native handles are still being released

Fix:

Remove the redundant stopService() call. The ACTION_STOP path in MhrvVpnService already handles the full graceful teardown (stop foreground → teardown on background thread → stopSelf). The extra stopService() is unnecessary and dangerous.

onStop = {
    val stopAction = Intent(this, MhrvVpnService::class.java)
        .setAction(MhrvVpnService.ACTION_STOP)
    startService(stopAction)
    // stopService(Intent(this, MhrvVpnService::class.java))  ← REMOVE THIS LINE
}

Steps to reproduce:

1. Start the VPN (tap Connect)
2. Wait for it to be fully running
3. Tap Disconnect
4. App crashes

Expected behavior:
App should stop the VPN gracefully without crashing.

Additional notes:
The MhrvVpnService.teardown() already has an idempotency guard (tornDown AtomicBoolean), which is correct for handling the onDestroy path. But the root issue is that stopService() shouldn't be called at all when we've already sent ACTION_STOP — let the service handle its own shutdown.

---

[therealaleph]

@ilok67 — confirmed root cause + fix. Applied in 1c9c2e0 (will land in v1.9.8): removed the redundant stopService() call after startService(ACTION_STOP) in MainActivity.onStop. The graceful-teardown path inside MhrvVpnService already calls stopSelf() at the end of the mhrv-teardown thread, so the second stopService() was just racing the lifecycle for no benefit. The tornDown AtomicBoolean protects against double-teardown of native state, but it can't protect against OS-level onDestroy racing the still-running teardown thread, which is what the user-visible crash was.

Zombie protection (the original reason stopService was added): startService(ACTION_STOP) already covers it — Android creates a fresh service instance in the new process if the previous one died, the teardown runs as a no-op on already-clean state, and the new instance stops via stopSelf. No extra stopService needed.

Thanks for the detailed analysis — this was exactly the right level of triage to ship a one-line fix off of.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}