Inconsistent issues launching mintupdate

[ra50]

Describe the bug mintupdate fails to start, but not consistently

When running mintupdate at the terminal several times in a row:

1. One time pops up a small window that doesn't render properly, where you can see through it to the application behind it.
2. One time doesn't open at all, with error in terminal:

   The program 'mintUpdate.py' received an X Window System error.
   This probably reflects a bug in the program.
   The error was 'BadLength (poly request too large or internal Xlib length erro'.

3. One time doesn't open at all, with error in terminal:

   The program 'mintUpdate.py' received an X Window System error.
   This probably reflects a bug in the program.
   The error was 'BadRequest (invalid request code or no such operation)'.

4. One time opens correctly.

Screenshots

To Reproduce Steps to reproduce the behavior:

1. Run mintupdate.

Expected behavior Expect it to open normally each time. Only expected terminal messages should be DeprecationWarning: Gdk.threads_leave is deprecated and Flatpaks: skipping update check - nothing installed.

Distribution:

• [X] Linux Mint 21.3 Xfce 4.18
• [ ] LMDE
• [ ] Other (please specify)

Software version: 6.0.9

Logs: This is in the log when mintupdate launches correctly.

03.07@17:06 ++ Launching Update Manager 03.07@17:06 ++ Changes to the package cache detected, triggering refresh 03.07@17:06 ++ Initial refresh will happen in 0 day(s), 0 hour(s) and 10 minute(s) 03.07@17:06 ++ Inhibited power management 03.07@17:06 ++ Starting refresh (local only) 03.07@17:06 ++ System is up to date 03.07@17:06 ++ Refresh finished 03.07@17:06 ++ Resumed power management

Crash report: /usr/lib/linuxmint/mintUpdate/mintUpdate.py:1379: DeprecationWarning: Gdk.threads_init is deprecated Gdk.threads_init() /usr/lib/linuxmint/mintUpdate/mintUpdate.py:1764: DeprecationWarning: Gdk.threads_enter is deprecated Gdk.threads_enter() /usr/lib/linuxmint/mintUpdate/mintUpdate.py:803: DeprecationWarning: Gdk.threads_leave is deprecated Gdk.threads_leave()

(mintUpdate.py:17432): Gdk-ERROR **: 17:07:08.835: The program 'mintUpdate.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'. (Details: serial 701 error_code 1 request_code 141 (unknown) minor_code 141) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)

Additional context Perhaps this is specific to my system, but not sure how to troubleshoot, have already tried reinstalling mintupdate. Seems similar to https://github.com/linuxmint/mintupdate/issues/868

Locale: LANG=en_US.UTF-8 LANGUAGE=en_US

[mtwebster]

Is this behavior new (maybe since you updated some packages), or has it been since you installed the system?

[ra50]

It definitely used to work fine on Mint 20.3 and works fine on a new 21.3 VM. I can’t say whether or not this has been occurring since updating to 21.3 or more recently. I did recently install and subsequently remove xorg-dev. That would seem related, but I checked and libX11 is still there and the version matches what’s in the fresh VM. Also no other apps are exhibiting issues. Do you have hints how else to debug or troubleshoot? I tried debugging and breaking on gdb_x_error and saw some dequeuing errors from xcb. Thank you.

[ra50]

When situation (1) occurs (small window pops up that is see through), the error received at the terminal is

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called

when executing Gtk.main().

[ra50]

This is an issue with making UI updates from background threads. Repeated attempts to stop on breakpoints before the error occurred usually led to error-free launches, which made it seem very much like a threading/race condition issue. As the error message implies, calling XInitThreads mostly resolves the problem:

import ctypes
ctypes.CDLL("libX11.so.6").XInitThreads()

This reduced the frequency of errors on launch but didn't eliminate them entirely. But it shouldn't be necessary if all UI updates are done on the main thread.

Since Gdk.threads_enter/leave are long since deprecated, I replaced them all with the recommended GLib.idle_add which resolved the launch errors completely for me (and also the warnings about the deprecated methods), without needing to call XInitThreads.

Do Gdk.threads_enter/leave still function or are they essentially no-ops since being deprecated? It's not clear why I was experiencing these errors on launch but other systems don't. Either way, the GLib.idle_add is the right pattern to use and resolves this issue.

Would you accept a PR with this change?

[mtwebster]

The Gdk.threads_enter/leave functions still do what they should, but it's definitely not the correct way anymore, and we don't use it with new code elsewhere.

We've stuck with them here because some places where they're would need a good amount of refactoring (I think during the install thread confirmations?

We did run into these errors briefly when we first added flatpak support, but haven't seen any other reports since - it's still puzzling why you'd be getting these only on one machine (assuming that's still the case).

Out of curiousity, how many cores does this machine have?

We'd accept a PR, but I think it's a bit too late in our development cycle to go in Mint 22 - Mintupdate is critical and I'd rather have a longer testing period for this sort of change.

ref: https://github.com/linuxmint/mintupdate/commit/eb6b6db956b6b7346f8fdea1d5779537a597080b

[ra50]

This machine is a Core i5-2500K which is 4 cores/4 threads. I don't experience the issue on a live CD on the same hardware or a fresh VM, but I haven't tested on any other systems. Since you say that threads_enter/leave do still work, I'm not sure why the issue occurs, it must be related to intricacies of how the "critical sections" function vs. just sending those calls to the main thread.

For InstallThread and elsewhere, I pulled the UI code into a method, and sometimes had to use nonlocal for variables that were defined outside of the method. I defined the method right above the idle_add call. It's not the prettiest and could use further refactoring but it gets the job done with minimal changes. Testing and verification shouldn't be too bad but I agree no need to rush release. I'll prepare the PR and get it your way.

Thank you!