Odd problem, multithread issue?

[Angii]

I've been just dealing with this problem for a while, but recently it happened to me abruptly immediately after reopening Pale Moon. I have a feeling that it may be something else in my setup causing this, but it only seems to have happened to pale moon the past few months, so I figured I should finally post about it. Every once in a while, Pale Moon will abruptly close itself. I started running it via a terminal so I could see what causes it, and every time it abruptly closes, it outputs:

Code: Select all

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted

I did a small amount of digging, and I haven't seen anyone else having this issue (let alone for the past monthish or so like I have), but I'm not sure what could be causing this to specifically affect Pale Moon, let alone Pale Moon across many versions. The builds this has been happening on are the ones installed via the official tool (pm-installer.sh) and not ones that I've compiled or anything. If anyone might have any insight, I thank you in advance; this has begun to confuse me a fair bit.

[Moonchild]

From what little I know (and I may be wrong) using xcb instead of xlib might not work very well; our cairo lib only has experimental support for xcb.
Not that I'd have any idea how to help you configure your X server to use something else though, but that seems to be a clue. Other people more familiar with X should chime in.

[Walter Dnes]

The builds this has been happening on are the ones installed via the official tool (pm-installer.sh) and not ones that I've compiled or anything.

Your personal builds are not crashing, while the official build is; correct? Maybe we can narrow things down by looking at the differences in the builds, to see what's causing the different behaviour. Which compiler are you using, and can you post your mozconfig? What distro (32/64 bits) are you using?

[Angii]

[...] our cairo lib only has experimental support for xcb. [...]

That could be it, I genuinely am not particularly knowledgeable about Xlib and xcb, so I suppose anything is possible here; I thought applications could choose which they wanted to use when both are present, but I could be mistaken for sure.

Your personal builds are not crashing, while the official build is; correct?[...] What distro (32/64 bits) are you using?

Ah, sorry for the misunderstanding, I was just saying that they were official builds so nobody thought it was just my own builds messing up; I have not tried compiling Pale Moon myself to see if that corrects the issue. Mozconfig is used in building Pale Moon/Firefox, right? I don't think I have one, as such. The distro I'm using is Void Linux (64bit), though; it's possible it's a distro issue, but I haven't seen any xcb errors on the distro's forums (first place I looked to, figuring it was a bad lib update or something). This genuinely does not generally happen that often, maybe every couple of days (sometimes not for a week+) of Pale Moon being open (but then sometimes multiple times in a row quickly upon reopening PM), dmesg never has anything to say during these times, either. I'm not sure where else I would look for relevant log information regarding the issue.

[Angii]

A small secondary question (I'm not a fan of double posting, but I just noticed this today), I noticed Pale Moon has a launch option (--sync) which has as its description: "Make X calls synchronous." Is it possible that this would solve my problem as a band-aid, so to speak? I'm not exactly sure what is causing the xcb error, but it seems (to my untrained eye, I guess) to be things somehow being lost in a sequence, so perhaps this would solve it? I'm not aware what --sync does beyond it's description, so it's possible it's entirely unrelated, but, I thought it might be worth an ask.

EDIT: Can already confirm it doesn't help, had the same issue pop up while running PM with --sync just to see if it helped at all. Oh well, that was worth a shot at least.

[vannilla]

XCB supports thread out of the box, so in a pure XCB setup there shouldn't be thread-related issues unless the programmer does some dark magic with the library (it is not 100% thread safe, even though normally there are no problems).

Threads are a problem with Xlib, and, in fact, what you see is an error from that library. It's prefixed with "[xcb]" because whoever is using XCB calls is configured to intercept events and errors generated by Xlib calls.
Since I don't know what uses XCB in Pale Moon, I can't think of any possible cause, but my guess is that there's something that normally would use XCB but for some actions require the use of Xlib, like OpenGL.

About the "--sync" flag, that has nothing to do with multithread, but with communication between the application (in this case Pale Moon) and the X server.
Most messages are asynchronous, as they send a request to the server which will apply them when the application says so (e.g. with XFlush).
Making them synchronous means that the server will apply the request as soon as it's received, which is the last thing you want (it makes things slower, and in some cases can actually cause problems).

I hope my explanation can help finding the issue (I never had this problem by the way).

[dinosaur]

To ensure Xlib (and all libraries consuming it) is properly initialized in thread-safe mode, you must make sure that XInitThreads() is called before any other call (direct or indirect) to Xlib.

In Pale Moon, this call appears in toolkit/xre/nsAppRunner.cpp (around line 3242 in current PM version), where you can see:

Code: Select all

#ifdef MOZ_X11
  // Init X11 in thread-safe mode. Must be called prior to the first call to XOpenDisplay
  // (called inside gdk_display_open). This is a requirement for off main tread compositing.
  // This is done only on X11 platforms if the environment variable MOZ_USE_OMTC is set so
  // as to avoid overhead when omtc is not used.
  //
  // On nightly builds, we call this by default to enable OMTC for Electrolysis testing. On
  // aurora, beta, and release builds, there is a small tpaint regression from enabling this
  // call, so it sits behind an environment variable.
  //
  // An environment variable is used instead of a pref on X11 platforms because we start having
  // access to prefs long after the first call to XOpenDisplay which is hard to change due to
  // interdependencies in the initialization.
# ifndef NIGHTLY_BUILD
  if (PR_GetEnv("MOZ_USE_OMTC") ||
      PR_GetEnv("MOZ_OMTC_ENABLED"))
# endif
  {
    XInitThreads();
  }
#endif

Obviously, if NIGHTLY_BUILD is undefined (or 0) and neither of MOZ_USE_OMTC or MOZ_OMTC_ENABLED environment variables are set, then XInitThreads() is *not* called.

I suggest systematically calling XInitThreads() instead (it won't hurt PM since Electrolysis is not used).

Note that some OpenGL drivers (e.g. NVIDIA's proprietary driver) will need Xlib to be initialized multi-threaded in order to be able to themselves use multi-threaded rendering.

[Moonchild]

@Dinosaur: If this was a systematic issue then Pale Moon would fail on ANY Linux/X11 system -- that's obviously not the case.
It would be interesting to know if setting MOZ_USE_OMTC solves the issue for the OP. If so, then for some reason they system assumes or uses xlib multithreaded even if consumers do not.

[dinosaur]

@Dinosaur: If this was a systematic issue then Pale Moon would fail on ANY Linux/X11 system -- that's obviously not the case.

Not systematic, no... There are so many desktop environments, window managers, compositors, plus X11, (X)Wayland versions, display drivers, not to count the amount of Linux distros, each with their own versions of the various libraries...

It would be interesting to know if setting MOZ_USE_OMTC solves the issue for the OP.

Yep, for a start...

Note that I am currently running a XInitThreads()-forced custom PM build, with no trouble whatsoever.

[Angii]

Thanks for looking into the problem, everyone! I've set the environment variable MOZ_OMTC_ENABLED=1 to see if this solves the problem; as the issue was rather sporadic (could go a week or more before having a sudden close) I won't know for sure if this has resolved the problem until nothing happens for a while, I suppose. I've stuck this into my /etc/environment as well to ensure I don't forget to set it whenever I restart my laptop. Again, thanks so much for the help, I know I never would've figured this out on my own, nor did I really know enough about Xlib/xcb to know where to start looking, either. If I don't have any sudden problems for a week or two I guess it's safe to assume setting the variable solved my problem and report back here. I'll swing back by if it doesn't solve my problem as well; although, if setting this environment variable ensures Pale Moon calls XInitThreads() I can't imagine it not solving my problem. Thanks again, everyone.

[Angii]

Weirdly enough, the sudden close just happened for me again. Same error as before was printed:

Code: Select all

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.

I was sure to check my environment variables afterwards, and yes, MOZ_OMTC_ENABLED=1 is still present; I'm not quite sure what to make of this now. I suppose it may be an issue with the xlib or xcb libraries present in my distro, but PM is the only program which experiences this problem. I suppose my next step is to try a fresh profile just to ensure there isn't some odd lingering issue there. As I'm the only one with this problem, I think it's fairly clear isn't a defect in Pale Moon however, so I'll mark this as solved and try that. Thanks for all the help, everyone! If starting a fresh profile solves it I'll be sure to post a note about it later.

[Moonchild]

Well, it's clear then that not calling XinitThreads isn't the issue. So, it was a nice theory, but alas incorrect.
If this was the case I would have expected to have heard from this much much much sooner, anyway.

[Walter Dnes]

Yes, I know "Pale Moon is not Firefox", but it still shares a lot of code. On the Gentoo mailing list, there's a similar report for Firefox. https://archives.gentoo.org/gentoo-user/message/b95e1d9f66afad5bb53f225ad35cf203 It may be related to a recent "upgrade" in components of X,

Since the last Xorg upgrade the week of May 20th, firefox seems to quit
(ie. crash) sporadically when I play chess on lichess.org. That leaves
me very unhappy There is a log message:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
firefox: /var/tmp/portage/x11-libs/libX11-1.6.5/work/libX11-1.6.5/src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

At first I thought this was a firefox problem because it was updated
about the same time. But then I intentionally downgraded firefox back
to what I thought was the "stable" version (52.6.0), and the problem
persists, so I now think it is X, either xcb or some other piece.

[Moonchild]

If anyone has more info or a related bugzilla bug to follow, I'd be interested.

[Walter Dnes]

If anyone has more info or a related bugzilla bug to follow, I'd be interested.

A bit of Googling turns up a couple of items

• A thread on stackoverflow https://stackoverflow.com/questions/18647475/threading-problems-with-gtk The "green checkmark post" suggests...

  Call XInitThreads(). This should be done before gtk_init, that will stop the messages!

• A thread at bugs.debian.org https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890882 suggests a workaround/kludge setting an external variable LIBGL_DRI3_DISABLE before launching. For Pale Moon this would be a script like

  Code: Select all

  export LIBGL_DRI3_DISABLE=true
  palemoon

[vannilla]

A thread at bugs.debian.org https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890882 suggests a workaround/kludge setting an external variable LIBGL_DRI3_DISABLE before launching.

I wouldn't unset DRI.
It's basically hardware acceleration.

https://en.wikipedia.org/wiki/Direct_Re ... astructure

[Moonchild]

Walter: see posts above -- XInitThreads does not fix the issue.

[linuxrocks123]

This issue has been a problem for me for some time after updating Slackware Current on my desktop; I've avoided updating Slackware on my laptop for fear of causing the problem to happen on it as well.

It appears this issue is happening with Fedora as well: https://forums.fedoraforum.org/showthre ... n-crashing

It must have something to do with a recent version of some library update; my guess would be libpthread-stubs from the fact that xcb is complaining. I'm willing to answer questions or do tests about the differences between versions of packages installed on my desktop and laptop if it would help narrow down what is causing this. It's frustrating because Pale Moon has become almost unusable on my desktop.

[OllyBain]

It's quite an annoying problem. It was not present in Fedora 27 (LXDE), but appeared for Fedora 28 (LXDE), with gigabytes of hard drive space vanishing after the crash. Now, I have switched to Manjaro LXDE, and it is still occurring. The error messages are the same. Could it be the LXDE library files as opposed to the choice of linux?

The error messages are still similar: (22 December 2018)
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

[vannilla]

Could it be the LXDE library files as opposed to the choice of linux?

Most likely.
After all, the X server isn't Linux-specific; it runs even on Windows.
Do the LXDE developers apply particular patches or special build configurations to GTK or whatever they use for their environment?