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

increase stability #774

Merged
merged 2 commits into from
Feb 4, 2023
Merged

increase stability #774

merged 2 commits into from
Feb 4, 2023

Conversation

ChristopherHX
Copy link
Member

  • use snmalloc instead of system allocator
  • synchronize x11 access

linux-packaging-scripts has been patched to use it
@ChristopherHX ChristopherHX marked this pull request as ready for review February 4, 2023 10:00
@ChristopherHX ChristopherHX merged commit 94bc336 into ng Feb 4, 2023
@trathborne
Copy link

Thanks! This makes Minecraft 100% stable on my quad-core haswell xeon + quadro p2200 5G with nvidia driver 510. On my dual-core haswell + geforce 730M 2G and nvidia driver 470, I still get xcb thread syncronization errors. I'm not sure if it's the different driver, the less powerful host, or the less video ram, or some combination thereof.

If there's some sort of trace that would help track this down, please let me know.

@ChristopherHX
Copy link
Member Author

I don't know how to debug this xcb thread synchronization errors.

I actually just added a mutex lock for every eglut / glfw api call, which may call x11 code.
I could have missed one or your xcb version is buggy.

I read that old xcb versions ignored that kind of threading issue so it is unlikely to happen on ubuntu 22.04.
Some semi current xcb/x11 client libraries seem to be more affected than the latest xcb/x11 client.

The x11 issues has been for me a very rare phenomenon even before I added the mutex synchronization

@trathborne
Copy link

Thanks for the details. My two systems are both up-to-date Ubuntu Jammy 22.04.1 so it can't be an xcb version difference. My guess is that the older nvidia driver and/or slower machine makes the problem more frequent.

I will try:

  • shifting the xcb version around as far as I can under Ubuntu 22.04.1
  • looking at your changes and trying to trace which eglut/glfw call triggers the problem
  • upgrading to Ubuntu 22.10

@trathborne
Copy link

I examined your changes ... so you take the lock before every eglut/glfw call, and taking the lock is idempotent so any other thread which uses these functions will block forever. Since I'm still getting that xcb error, there must be another thread that does not use that lock making the call. I can only conclude that it's in code for which we don't have the source, so even if we can find where it is, we probably can't fix it. ☹️

I'm holding off on my Ubuntu upgrade but I'll let you know if that helps.

In the meantime ... Minecraft Java works great 😉

@ChristopherHX
Copy link
Member Author

I can only conclude that it's in code for which we don't have the source, so even if we can find where it is, we probably can't fix it.

You can use wayland, the game doesn't use xcb, or it is memory corruption that happens randomly.

Configure the launcher to use glfw, tell glfw to use wayland and all xcb error are compiled away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants