Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement client watchdog #4081

Draft
wants to merge 1 commit into
base: 1.21.2
Choose a base branch
from

Conversation

apple502j
Copy link
Contributor

Note: will refactor once #4052 is merged.

Client watchdog works similarly to the dedicated server watchdog - but for render thread. When the client ceases to tick for 30 seconds (or fabric.clientWatchdog.maxTimeMs), the game forcibly crashes. Useful for debugging infinite loops and the like.

This feature is currently enabled only in dev (or with fabric.clientWatchdog.enabled).

TODO:

  • Maybe try to save the integrated server?
  • This currently logs non-fatal error due to off-thread native access. Not sure if this is worth fixing. The error is not present in the watchdog crash report.

@apple502j apple502j added the enhancement New feature or request label Sep 10, 2024
@apple502j apple502j force-pushed the crash-report-info/client-watchdog branch from d794aa1 to 4de277f Compare September 10, 2024 02:28
Copy link
Member

@modmuss50 modmuss50 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im not sure how useful this is, but its easy enough. a few minor points.

}

public void run(MinecraftClient client) {
while (client.isRunning()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there not be a sleep in this while loop, there is no need to constantly check the value. See: DedicatedServerWatchdog

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah, whoops.

import net.fabricmc.fabric.mixin.client.crash.report.info.MinecraftClientAccessor;
import net.fabricmc.loader.api.FabricLoader;

public class ClientWatchdog implements ClientModInitializer {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

really needs a testmod, id add a client command that sets a bool, and in the client ticket event just have a while (bool)

@apple502j
Copy link
Contributor Author

im not sure how useful this is

Well, a watchdog is useful in any part of code that might do infinite loop.

@embeddedt
Copy link
Contributor

IMO, a watchdog for the integrated server thread (in production) would be vastly more useful than one on the client thread. It's pretty rare that released mods deadlock the render thread. However, it's quite common for the integrated server to freeze with no explanation.

@modmuss50
Copy link
Member

I agree with @embeddedt however I think we also need to be careful to not trigger it too egarly, and maybe not crash to desktop? It could possibly open a UI allowing the user to ingore it?

With this PR as is, if you stall the main render thread will windows show the not responding UI?

@apple502j
Copy link
Contributor Author

Ah yeah, integrated server needs a watchdog as well. Will do that. I doubt it will have that much of a side effect if it only applies on dev/is opt-in.

If the server is not ticking for 30 seconds, I think it's fair to say it crashed. I don't want to overcomplicate things (remember this is FAPI).

With this PR as is, if you stall the main render thread will windows show the not responding UI?

Need to check later. Without this PR it does show that UI.

@modmuss50
Copy link
Member

By UI I mean just a simple miecraft yes/no screen asking the user if they want to quit. I just worry someone is going to want to run a massive command that takes a long time to complete, and 30 seconds wont be enough.

@embeddedt
Copy link
Contributor

IMO the integrated server watchdog should not be enabled in dev, only in prod. At the very least, it should be disabled if a debugger is attached, otherwise pausing at a breakpoint for a while is enough to trip it, which makes it an inconvenience.

@sfPlayer1
Copy link
Contributor

It might have some extra uses in-dev with a shorter delay to ungrab the mouse, especially on Linux.

I'd like to see less use of MC's utility methods where the JDK has suitable alternatives to reduce porting efforts.

@apple502j apple502j marked this pull request as draft September 13, 2024 17:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants